The future of SMF

[Arantor]

but what events of recent weeks?

How could you forget the 9 page topic elsewhere on this?

And what transparency

Like the fact that no-one on the team is going to stand up, here, and actually admit 1) there's a problem, 2) that the problem needs fixing and 3) talking to the community about fixing it.

For example... this whole debate on the copyright. It's a pretty big issue that affects anyone who's ever contributed to the project's source code at any point, including people committing via GitHub with a DCO. But had it not been for Norv doing what we both agree was handled badly, plus (months later) taking it to a lawyer, plus having to be pushed multiple times, before there's anything resembling a conclusion.

Oh wait. Would that be the conclusion where things have been done and *nobody knew about it*?

This is one of the cornerstones of a community: communicating between yourselves. It's certainly clear that there has been a great deal of misunderstanding (mostly) and miscommunication (a little, but mostly it's not intentional, nor is it malicious in nature)

I found it hilarious that an official representative went and spoke to ElkArte (only to be accused of stirring up drama) and not to us, though by the time that had happened, I'd already been told by multiple people the way things were headed - and I'm not a team member, thank the deities. So there's another problem.

I don't know what you've been accused of lying about...

Neither do I.

but if it was the comment that Nao made above, about Elkarte folks and the statement from the lawyers regarding copyright, I will state that, whoever claimed on Elkarte that "they were right all along" was hallucinating and has it completely turned around.

Firstly, the phrase was 'mostly right'. Secondly, that is a dramatic oversimplification, but as we hammered out at wedge.org, they actually were kind of right, certainly more correct than what was there before.

This would be the same 9 page discussion where you spent a great deal of time telling me I was wrong, even though I pretty much called it the same way the lawyers did. Funny that.

We shouldn't even be having this conversation. It shouldn't be necessary because it shouldn't need me - an outsider to all intents and purposes - to act as a sort of watchdog, or play referee, however you want to call it.

We shouldn't be having this conversation because instead of talking to the community about it and explaining what was going on and why (you know, being transparent), there should have been an announcement which would have probably settled the matter. Small wonder there have been accusations of copyright grabbing, though they're probably as spurious as other claims. At least, I'd like to think so.


So, what's the real state of smCore? What's the real state of SMF 2.1? Your community is watching. They deserve to have their faith rewarded.

[LiroyvH]

Like the fact that no-one on the team is going to stand up, here, and actually admit 1) there's a problem, 2) that the problem needs fixing and 3) talking to the community about fixing it.

I think that might show more that not being on the team and only acting on "what I've heard" may show it's better if internal material stays being handled internal and release what's prudent to be released on own accord, as wrong conclusion can be drawn easily based on "what i've heard", as I think you know pretty well.

Of course, you are entitled to your own opinion.

For example... this whole debate on the copyright. It's a pretty big issue that affects anyone who's ever contributed to the project's source code at any point, including people committing via GitHub with a DCO. But had it not been for Norv doing what we both agree was handled badly, plus (months later) taking it to a lawyer, plus having to be pushed multiple times, before there's anything resembling a conclusion.

As you say, handled badly. I think there isn't much debate required on that.
The problem has been fixed. Whether that took a while to make sure it was done thoroughly or not is subject to debate, perhaps, but i'm not sure what people rather see: doing stuff without thinking or talking (ergo: handling it badly) or making very sure everything is done correctly... The latter usually takes more time. And sure, you may label that as slow. To me, I feel the end result is most important: is a problem fixed or not? Yes? Good.

I guess it's a matter of personal favor.

Regarding communication and nobody knew about it: True. But, I think you know why nobody on the team knew about the, now perfectly (imho) solved, issue.
You said it yourself, it was handled badly by a, at that point, third party.

Neither do I.

I had actually hoped you would rephrase that post, I know you have seen that I had corrected your assumption. As such: "Neither do I?" That makes two of us.

they actually were kind of right, certainly more correct than what was there before.

Nobody denied there was a problem. It was just pointed out there was a major flaw in the extraordinary poor way it was executed, with which for the latter part you seem to agree.

And as you so elequently put: communication is key.
When there is none... Well... Can't expect something to change if a problem is not presented to the responsible team in any way. No psychics around here.
Another example of that is the recent security issue that was patched with SMF 2.0.4. We would have never known about it if it was not reported by the person who found the security leak. But, that person chose to inform us and the security problem was fixed very fast by the excellent effort Emanuele put in to it. Had nobody told us about that issue, it would be impossible to know about it and thusly it would not have been fixed.
And that goes for any type of problem. Without telling the team if they are unware: it will not be fixed as you need to be aware of a problem before you can patch it up.

We shouldn't be having this conversation because instead of talking to the community about it and explaining what was going on and why (you know, being transparent), there should have been an announcement which would have probably settled the matter. Small wonder there have been accusations of copyright grabbing, though they're probably as spurious as other claims. At least, I'd like to think so.

Well perhaps, instead of playing referee or how ever you wish to call it yourself, you should actually leave it up to the team to work on releasing news when the need is there, how and how fast. Perhaps instead of saying everything should be done instantly, you should leave it up to the team to chose what, how and when to do something.
Perhaps your preference is to rush things and ours is not.
I by no means wish to offend you, but... Perhaps I will, by saying: I think you may sometimes rush things too quickly. For example the previous post you made was done in an extreme rush based on a wrong assumption. That's why I personally enjoy seeing people taking their time before taking action.

Does that really make SM/SMF so bad because the opinion on speed differs?
Like I said, I think that's a matter of opinion and personal preference. You can choose to do that differently, of course.

I mean, you started a fork because you have different ideas about the software and everything. While the way of working there may work for you I'm not sure why you think it should work that way for everyone. If my conclusion is correct on that you think as such, anyway. I might be completely wrong. After all, i'm just drawing conclusions here as well based on what you said; but words can most obviously be misinterpreted.

Don't get me wrong by the way, I hope you don't see this as an attack to you. You share your opinion, I share mine. Before you, like on the messenger, draw the wrong conclusion on what I'm saying: I enjoy your presence and effort here, most of the time anyway lol, and it is a good thing you express your, passionate I might add, opinion. Let us be clear on that.
I do hope you respect my views on things as well, though. Mutual respect is important imho.

So, what's the real state of smCore? What's the real state of SMF 2.1? Your community is watching. They deserve to have their faith rewarded.

Indeed, they do. So rather than making assumptions, perhaps patience is more in order and let SM/SMF decide on when to release whatever there is to release if/when anything news is there to be released, rather than wanting people to rush it.
We're not in a rush and take time extensively to see what the best way forward is with all projects under the SM umbrella, including but not limited to smCore. Projects are being checked and when anything new is there to be announced: the community will always be informed. We haven't done anything else in the past, nor will we in the future. I'm not sure where you get the idea from that SMF would not keep the community informed.
But... when you're not on the team or NPO group, it is of course hard to know all the ins & outs on the status of projects, status of news releases, whatever. And again, personal preference.


The state of SMF 2.1 isn't so hard to find by the way: it is moving forward properly. Perhaps somewhat slow compared to other forum software out there, but SMF doesn't exactly have a reputation of being lightning fast with releases and I personally don't think there is anything wrong with that.
SMF 2.x is a rock solid SMF edition, making new releases simply for the sake of releasing is pretty much not how SMF has rolled in the past and I don't think it should ever.
You may disagree with the speed, but I personally do hope you do not disagree with the statement that the releases that SMF does make are very stable and as bug-free as possible. Perhaps personal preference on some pieces of code aside Quality over quantity, that's what, at least in my experience and opinion, SMF is about.

That's all.

[Arantor]

I think that might show more that not being on the team and only acting on "what I've heard" may show it's better if internal material stays being handled internal and release what's prudent to be released on own accord, as wrong conclusion can be drawn easily based on "what i've heard", as I think you know pretty well.

Of course it can. That's part of the problem. The fact that nothing ever seems to happen without some kind of issue flaring up to prompt some kind of action. See point about *transparency*.

I shouldn't have to make inferences about this stuff. This is one of the reasons SMF finds it so hard to recruit developers, because no-one wants to trust it, and with good reason given what's happened before - once they get behind The Wall, they see how it really is, how it's been for years.

I can only speculate that this is the big reason behind keeping things 'under wraps'.

The problem has been fixed. Whether that took a while to make sure it was done thoroughly or not is subject to debate, perhaps, but i'm not sure what people rather see: doing stuff without thinking or talking (ergo: handling it badly) or making very sure everything is done correctly... The latter usually takes more time. And sure, you may label that as slow. To me, I feel the end result is most important: is a problem fixed or not? Yes? Good.

You mean a problem that most wouldn't have even realised SMF had, had it not been pre-empted? A problem that some people are pretending didn't exist and that wasn't a problem in the first place?

A problem that those impacted by it may not even have been contacted about yet? (Those who signed a CLA and committed material while the CLA was still in force, they're probably assumed to have consented. Anyone else, e.g. DCO contributors... that's a different matter.)

Well perhaps, instead of playing referee or how ever you wish to call it yourself, you should actually leave it up to the team to work on releasing news when the need is there, how and how fast. Perhaps instead of saying everything should be done instantly, you should leave it up to the team to chose what, how and when to do something.

Here's the thing. I shouldn't have to get involved. But I don't feel I can sit back.

Take the current copyright issue. How long has that been going on? How many months ago was it that a developer, who by then had left, whose access to the repository hadn't been removed, came back to quietly make a huge change? Without even getting into the 'how did it happen' malarky... why did it take so long to figure out that going to a lawyer was necessary? Why wasn't a lawyer consulted as soon as the NPO took over, to clarify what the NPO actually had copyright to? (Because if it was, none of this would have been an issue in the first place) But instead it was done over 18 months later, only after someone had already tampered with it.

This is the sort of issue that really gets my goat: SMF is floundering by any measure you care to name, and a lot of that is managerial issues.

Does that really make SM/SMF so bad because the opinion on speed differs?

There's slow, there's slow, and there's what I can only call burying heads in sand and hoping the problem goes away.

Don't get me wrong by the way, I hope you don't see this as an attack to you.

It's not an attack on me, nor do I see it as one. You're one of the few people I've had the pleasure of talking to who can actually attack a position, not a person. In reciprocation, I'm trying hard not to target a single individual for anything that's gone on here. I don't care who did (or did not) do something. I'm just annoyed that stuff isn't happening when if SMF wants to survive, it needs to start happening.

We're not in a rush and take time extensively to see what the best way forward is with all projects under the SM umbrella, including but not limited to smCore. Projects are being checked and when anything new is there to be announced: the community will always be informed. We haven't done anything else in the past, nor will we in the future. I'm not sure where you get the idea from that SMF would not keep the community informed.

Well, let's see... no-one appears to be saying or doing anything about the fact that smCore is dead and isn't going to be relaunched in any practical form (seeing how all of its contributors left). So, what's the plan?

Here's the thing: SMF is a project in dire need of competent developers. No developer is going to magically come along and rescue the project, especially not with all the horror stories. I keep hearing talk of how it's all different now, but I'm just not convinced.

But anyway, the question of the hour: does anyone have anything resembling a plan at all? Is anyone going to share with the community what that plan might be?

What's left to do in 2.1? If anyone had any idea of what was missing, maybe you'd get some help.

Is there going to be a 2.2? Or will the next version be 3.0? What's the plan for these things? Is there a plan? Assuming there is a plan and someone has some idea what's going on, who's going to go build it?

Which brings me back to the small matter of the lack of devs. If you communicate with the community about the plan, there is a small chance - and it is, sadly, small, though not as small as straight up wishful thinking - that a developer might be inclined to get involved.

I am aware that even discussing this issue publicly is going to put potential developers off as things stand - but I'm also aware that people who go into something with the best of intentions might be soured by what they find. Forewarned is forearmed, as they say.

The state of SMF 2.1 isn't so hard to find by the way: it is moving forward properly. Perhaps somewhat slow compared to other forum software out there, but SMF doesn't exactly have a reputation of being lightning fast with releases and I personally don't think there is anything wrong with that.

There's only one software going more slowly than SMF right now, and that's XenForo.

As for not having a reputation of going 'lightning fast', there's another reason why all the momentum left and took most of the competent developers with it. Not going 'lightning fast' is one thing, but taking 18 months to get to the level of perceived change in 2.1 seems... slow. I've tried 2.1, and while what there is is good (and due credit to the people who made it what it is), it doesn't really feel like a huge step forward.

Before anyone waves the 'but Wedge has had 2 1/2 years', yes it's had 2 1/2 years. It's also had tens of thousands of lines of iterations and coming up to 2,000 (SVN, not Git) commits, including a redesigned theme engine, a rebuilt from scratch package manager and so on. Small changes like what 2.1 looks like should not take 18 months.

I'm well aware that things take time, and that quality should not be rushed, but this seems wrong somehow.

SMF 2.x is a rock solid SMF edition, making new releases simply for the sake of releasing is pretty much not how SMF has rolled in the past and I don't think it should ever.

It is pretty solid, yes, necessitating 4 patches in 1 1/2 years is good going (for comparison, SMF 1.1.x had 18 patches across 6 1/2 years, roughly 3/year). But if you're not going to release, need to keep in touch with users, to let them know what's going on. I find this very topic hilarious, given that it was set out by the previous lead dev last year about a plan that doesn't seem to be going anywhere.

[青山 素子]

I haven't been all that active in the daily project stuff, not being a project member, but I'll try to comment on a few things.

This is by no means any kind of official statement. It's simply my personal opinions. It is possible that the BoD or Simple Machines may disagree with some things I post.

The fact that nothing ever seems to happen without some kind of issue flaring up to prompt some kind of action. See point about *transparency*.

Agreed that it's a bad way to do things, but it seems that nobody really tries to call out concerns in any way other than something that causes internal fighting. Not that it's a solid rule, mind you. Some people do actually bring up concerns in a less-dramatic way. However, drama seems to be the norm.

I shouldn't have to make inferences about this stuff. This is one of the reasons SMF finds it so hard to recruit developers, because no-one wants to trust it, and with good reason given what's happened before - once they get behind The Wall, they see how it really is, how it's been for years.

Would you argue for read-only access to the general public for all internal boards (save for some areas limited where sensitive info can be discussed)? Just curious on how transparent you feel things should be.

I can only speculate that this is the big reason behind keeping things 'under wraps'.

At least some of it is for "information management". Basically, determining what the best way would be to post certain things. Nothing nefarious, but sometimes just putting out raw info can lead to all kinds of misunderstandings, especially with preliminary info.

You mean a problem that most wouldn't have even realised SMF had, had it not been pre-empted? A problem that some people are pretending didn't exist and that wasn't a problem in the first place?

If it had been brought up in a less dramatic way, it might have been handled better. Maybe. We'll never know, since that wasn't what happened.

A problem that those impacted by it may not even have been contacted about yet? (Those who signed a CLA and committed material while the CLA was still in force, they're probably assumed to have consented. Anyone else, e.g. DCO contributors... that's a different matter.)

I believe the CLA would cover any adjustment of the copyright line. Also, AFAIK, the line simply updated the understanding to match the new DCO. The legal counsel was provided with the paperwork covering both the old CLA and the new DCO.

However, it's a good question to see if contributors need to be contacted/notified of the change. I'll forward that concern so it can be checked.

Take the current copyright issue. How long has that been going on? How many months ago was it that a developer, who by then had left, whose access to the repository hadn't been removed, came back to quietly make a huge change? Without even getting into the 'how did it happen' malarky... why did it take so long to figure out that going to a lawyer was necessary?

I think right after that change, it was figured out that it was really important to check with someone with legal experience on a proper wording. So, the answer to that would be on the order of minutes to hours. The insane fighting over reverting it to the old wording while a check was being done really delayed the actual work on obtaining legal advice.

Why wasn't a lawyer consulted as soon as the NPO took over, to clarify what the NPO actually had copyright to?

Can't speak to that one, I wasn't part of the team that handled that stuff. I can only speculate that with all the other work of moving ownership, it was overlooked. Too bad it wasn't suggested to review it sooner.

This is the sort of issue that really gets my goat: SMF is floundering by any measure you care to name, and a lot of that is managerial issues.

Agreed, mostly. There are managerial issues, but it seems a lot of people involved take anything very personally. It makes it difficult to get anything moving when there are people fighting entrenched positions who don't like "compromise" or other such words. Add to that the seeming lack of desire to actually be part of the management of the project, and you wind up with a very few people who are overworked doing what amounts to a second full-time job in their spare time.

Seriously, it's painful to see people leave the corporation and give up their voting rights who then complain and throw a fight when something is done that they don't like. They could have voted against it if they were involved, but they gave up that ability.

Before anyone waves the 'but Wedge has had 2 1/2 years', yes it's had 2 1/2 years. It's also had tens of thousands of lines of iterations and coming up to 2,000 (SVN, not Git) commits, including a redesigned theme engine, a rebuilt from scratch package manager and so on. Small changes like what 2.1 looks like should not take 18 months.

Well, at least some of the time was re-assembling a development team from the pieces left after the project changed ownership. Also add in the time taken to get all the structure set up and having the developers discuss a roadmap. Oh, and the fight over pinning the future on smCore (and abandoning any development on SMF 2 except for security fixes) versus running small development sprints on 2.x while smCore was built. Good thing development continued on 2.x, smCore is basically dead.



I think that's enough for now. I welcome further discussion.

[LiroyvH]

Of course it can. That's part of the problem. The fact that nothing ever seems to happen without some kind of issue flaring up to prompt some kind of action. See point about *transparency*.

I shouldn't have to make inferences about this stuff. This is one of the reasons SMF finds it so hard to recruit developers, because no-one wants to trust it, and with good reason given what's happened before - once they get behind The Wall, they see how it really is, how it's been for years.

I can only speculate that this is the big reason behind keeping things 'under wraps'.

Well, I guess that's a matter of perspective.
Like I pointed out: problems cannot be solved if they are not put to attention of the team.

The methods of contacting the team are there, and there are a lot of them.
You seem, and please do correct me if I'm wrong, to imply that each and every *potential* problem that could be in SMF has to be known by the team. See my reference to the security issue that 2.0.4 patched how that's not possible. And I do have my doubts when typing this because I know you're quite reasonable with the reasoning, so perhaps I am not fully understanding what it is you want here. Anyway, yes: some issues require an action before it prompts action from the team.
I don't consider that to be anything strange. I'm not sure why "conventional methods" could not be used to make the team aware, though.
I do agree whole heartidly that it is sometimes excruciatingly difficult to get something moving around here. No doubt. But... That's what happens when you're working with volunteers. People have lives. (At least, some of us *grin*)

Well, I indeed think you shouldn't have to nor do I think you should have. And just for the record: By that I'm not implying you shouldn't give your opinion. It's just a mere observation from my perspective that makes me conclude that there was indeed not much need to do that. We can obviously disagree.
I think we are a bit on a different page on that aspect, anyway.
I would disagree with the "behind the wall" thing, but making an educated guess here I think it will best to agree to disagree on that part, heh.

As for keeping things "under wraps", I must say I totally disagree with you on that.
Nothing important is being kept under wraps here at SM. You may disagree, again, on the speed... But that's a personal preference.
I think we're quite, if not very, transparent and share a lot with the community and I think me (openly I might add) debating this with you is quite the proof of that, but indeed: all in good time whenever there is something to be released eventually. First things first. Just like with releases, things are ironed out completely until there is no, to the best of the available knowledge, problem left and ensure it is fixed for the full hundred percent before moving forward.
It's almost as if you feel we should make the FTC a completely publicly visible board. For the record: I know that's not what you're suggesting, but you are making a imho unfounded accusation that things are being kept under the wrap but it seems solely based on your feeling that come forth out of a, in your eyes, speed issue. You mistake speed, or lack thereof, for deliberate silence. That is not the case though. I think this may be a problem because you are commenting on project related issues of which you obtained some information, but you cannot see the developments. In short: you are commenting on a team based issue without being on the team. That may lead to some misinterpretations and wrong assumptions because you cannot get accurate updates on the information you have been fed.

While opinions may defer on the speed, I'm not sure why to choose, I guess, not to respect the way SM/SMF handles it. You can disagree on how it's done and/or how fast, of course, but does that warrant releasing info ever so slightly this way? I'd say no, but that's rather irrelevant at this point.
You claim, while not being able to see everything, that it was chosen not to disclose anything, but that's something only someone outside the team can assume and indeed: speculate on. That doesn't necessarily make it a true fact, as it is not.
I think it all boils down to a difference in opinion. In the end, it's debating something in progress, unreleased.

If things would have truly been kept "under wraps", wouldn't I have removed all your posts and banned you by now?

You mean a problem that most wouldn't have even realised SMF had, had it not been pre-empted? A problem that some people are pretending didn't exist and that wasn't a problem in the first place?

Well, like I said, you cannot seriously expect a team to know about each and every problem a piece of software may have.
Again, I'm referring to the way we learned about the SMF 2.0.3 security issue leading to the 2.0.4 patch. If nobody talked to us: there would most likely not have been a 2.0.4 yet and the vulnerability would slumber still.
Many things, such as bugs (I mean, take the SMF 2.1 repo, if we didn't have beta testers... woo. ) are squashed by the team. But not *everything* can be known to the team at all times, even despite the rigorous checks.
I won't apologize for the project being imperfect

Take the current copyright issue. How long has that been going on? How many months ago was it that a developer, who by then had left, whose access to the repository hadn't been removed, came back to quietly make a huge change? Without even getting into the 'how did it happen' malarky... why did it take so long to figure out that going to a lawyer was necessary? Why wasn't a lawyer consulted as soon as the NPO took over, to clarify what the NPO actually had copyright to? (Because if it was, none of this would have been an issue in the first place) But instead it was done over 18 months later, only after someone had already tampered with it.

The need for that became clear within a matter of days in order to sort it out once and for all.
Finding a suitable solution is another story, but again: While you may feel rush should be the way to go and a fix should be there within a matter of minutes, I don't think that is the way to go at all. Sure, it went slower than it could have went, but what does that matter if it is sorted out properly eventually? This is a volunteer project, it's not exactly people being paid to work around the clock.
Better make sure it's done right and, as this project doesn't run on water, without costing tons.

When the NPO took over there was a different situation, by the way. Please do not forget that.
The issue you are referring to was *not* an issue when the NPO was formed, or that is to say: Not in it's current form, it was handled differently at the time. Changes over the years however generated a new problem that was indeed not seen at first sight. And it pretty much isn't an issue anymore now though.

There's slow, there's slow, and there's what I can only call burying heads in sand and hoping the problem goes away.

Well, you're free to call it what you want, heh. I am glad to tell you it's not the correct assumption to make though. It is regrettably indeed an assumption, and it's too bad you think so negative about it. That's up to you, of course. But please, don't make the mistake of seeing that assumption as a immediate fact.
You'd be surprised! And I hope you will be pleasantly surprised in the (near) future, even though you, like I am as well, can be hard to please in my experience.
Just... Patience! (I'd almost add "young Padawan!" to that, but you're near officially OLD. No worries, you don't have to thank me for saying that. )

It's not an attack on me, nor do I see it as one. You're one of the few people I've had the pleasure of talking to who can actually attack a position, not a person. In reciprocation, I'm trying hard not to target a single individual for anything that's gone on here. I don't care who did (or did not) do something. I'm just annoyed that stuff isn't happening when if SMF wants to survive, it needs to start happening.

I am glad to hear that. Oh I think you succeed pretty well in that, you seem to target it "as a whole" rather than pointing multiple fingers at multiple individuals. I applaud that.

Well I could start with a horrible cliche here that has something to do with Rome, heh, but let me just point out that I don't see much threats to SMF's future. Even though indeed, the past is something to learn from and that's a good thing: better the process, better the environment. There have most certainly been some mistakes, some good things mistaken for mistakes and good things in a whole. It just strikes me that people in general usually solely focus on the negative instead of the good and the bad, and that on my part slightly annoys me heh. But, that would almost indicate I have no right to be on the internet; the internet is nearly all about complaining rather than applauding or a combination of those two these days. Opinions can be annoying/offensive, dealll wiithhh itttt. I probably offended enough people with my opinions, so it would be a bit hypocrite to start boohooing over an opinion of someone else myself, LOL.

Well, let's see... no-one appears to be saying or doing anything about the fact that smCore is dead and isn't going to be relaunched in any practical form (seeing how all of its contributors left). So, what's the plan?

All in good time. Appearances can be deceiving, might I just note that. And you can ask anyone on the team to confirm that if you do not wish to take my word for it.

Here's the thing: SMF is a project in dire need of competent developers. No developer is going to magically come along and rescue the project, especially not with all the horror stories. I keep hearing talk of how it's all different now, but I'm just not convinced.

Indeed it is. Or that is to at least say: More of them!
As for horror stories... Meh. We do not have to agree, I guess.
I think that perhaps a whole fresh load of devs might prove to be a different situation than the same people being involved all the time. Fresh winds and bla.

But anyway, the question of the hour: does anyone have anything resembling a plan at all? Is anyone going to share with the community what that plan might be?

Yes.

What's left to do in 2.1? If anyone had any idea of what was missing, maybe you'd get some help.

Is there going to be a 2.2? Or will the next version be 3.0? What's the plan for these things? Is there a plan? Assuming there is a plan and someone has some idea what's going on, who's going to go build it?

Well, perhaps that's a good thing to ask the developers.
Duly noted: you, and probably more people, are in need of a status update on 2.1.
Granted, I do not think the developers will have any problems at all divulging that information and I would be very happy if people stepped up to help: it may speed things up! Help is appreciated and it is what makes it community driven.

For 2.2 and 3.0 and let me rephrase that in to a word that catches it all: A roadmap, I will refer back to the developers again. It's as they say not my party nor my area of expertise or prime activity.

Which brings me back to the small matter of the lack of devs. If you communicate with the community about the plan, there is a small chance - and it is, sadly, small, though not as small as straight up wishful thinking - that a developer might be inclined to get involved.

I am aware that even discussing this issue publicly is going to put potential developers off as things stand - but I'm also aware that people who go into something with the best of intentions might be soured by what they find. Forewarned is forearmed, as they say.

For 2.1 there is no immediate lack of developers, but as always: we are looking for talent.

Well, I hope it does not. Nobody bites ya know.
But sure, everyone could be disappointed, but it can go another way as well: sheer happines to be working on a still very much promising project. Past is past, and the past has given valueable lessons.
Although that is not to say you may ofcourse 100% agree on working methods, I guess that's what lead to your fork spawning, for example.

There's only one software going more slowly than SMF right now, and that's XenForo.

As for not having a reputation of going 'lightning fast', there's another reason why all the momentum left and took most of the competent developers with it. Not going 'lightning fast' is one thing, but taking 18 months to get to the level of perceived change in 2.1 seems... slow. I've tried 2.1, and while what there is is good (and due credit to the people who made it what it is), it doesn't really feel like a huge step forward.

Before anyone waves the 'but Wedge has had 2 1/2 years', yes it's had 2 1/2 years. It's also had tens of thousands of lines of iterations and coming up to 2,000 (SVN, not Git) commits, including a redesigned theme engine, a rebuilt from scratch package manager and so on. Small changes like what 2.1 looks like should not take 18 months.

I'm well aware that things take time, and that quality should not be rushed, but this seems wrong somehow.

I'll take your word on XenForo, I don't know them.

Well, in regards to SMF 2.1. I guess it's a matter of taste. And perhaps also a reason why you took the road of creating a fork.
Whilst SMF 2.1 might not be a complete rewrite and a new SMF from near scratch, I'm not sure if it has to be.
SMF 2.1 will be offering some splendid new functionality, rewritten parts, patched up current functionality, more in par with "today's world", et cetera. Is it a 100% new product? Nope. Does it *have* to be? Imho: Nope.
There are even still people on SMF 1.x (sadly, also on 1.0.x, although it does show how much of a robust product SMF is which makes me quite happy.) that haven't even touched SMF 2.x. It shows SMF on it's self is a highly solid product which covers the needs of many people. Had it not, we wouldn't have so many users, of course.

You're free to be disappointed because you had hoped to see far more changes and a 100% new SMF product, but I have a opposite preference: I like SMF sticking to it's root in large lines but DOES take wishes of the community, and of course: self made up new functions, rewrites, etc, in mind with the upcomming SMF 2.1. It's a blend of both... Innovating, renewing and changing while, however, sticking to roots that made SMF such a major succesful piece of software in the first place, the product that is loved by many people. I think 2.1 shows to be a perfect combination of innovation, based on community feedback and ideas of the team, and staying true to the essence of SMF itself by not making a 100% new product.
(My god, that whole part sounds horribly OMG MARKETING!!1! but it is my sincere personal opinion on the software.)

I mean, if you look at it that way: SMF 2.x wasn't a super huge change over SMF 1.x either: SMF 2.x also remained true to it's roots set out in SMF 1.x. Did it come with new functionality, a new design, large rewritten parts: Absolutely. But in essence, SMF is still SMF. The same is happening with SMF 2.1. Although, I ofcourse must admit SMF 2.x did have some *major* code differences over 1.x. (That is NOT to say that 2.1 doesn't have that. But, perhaps less than what you personally had hoped for. Which is probably another reason why you chose to make a rewrite of your own.)

Perhaps it could have been done faster, perhaps it could not have been. We had a few setbacks.
But... SMF 2.1 is getting closer to a release each day that passes. And that is a prime example of what I see as a good thing.
Yeah, you can certainly argue it's taken it's damn time... But you can also look on the bright side of life (yep, that was a reference.) and focus on happy thoughts: It's getting closer to RC status day by day.

It is pretty solid, yes, necessitating 4 patches in 1 1/2 years is good going (for comparison, SMF 1.1.x had 18 patches across 6 1/2 years, roughly 3/year). But if you're not going to release, need to keep in touch with users, to let them know what's going on. I find this very topic hilarious, given that it was set out by the previous lead dev last year about a plan that doesn't seem to be going anywhere.

SMF 2.1 will most certainly be released.

But, I think I sense a reference to something else in there... On that part, I would ask you to have patience.
You're asking to receive a basket full of cookies at once. There will be news.


Thanks

[Arantor]

Like I pointed out: problems cannot be solved if they are not put to attention of the team.

Agreed. Is the team acknowledging that there is a problem? Is the team acknowledging the fact that they have a serious problem with recruiting developers to build software (around which everything is based)?

Are they acknowledging the reasons that have been given to them repeatedly by different iterations of developer team about why they're leaving? (The conversation on Wedge suggests this is not the case.)

You seem, and please do correct me if I'm wrong, to imply that each and every *potential* problem that could be in SMF has to be known by the team.

SMF or SM organisation? Let us assume the latter, as that is what I was referring to. And refers to my previous point.

Successive generations of developers have left. Each have cited the same core reasons why they have left, with modest variations, but the core reasons remain unchanged. This has been going on for years. I would presume the team are aware of them by now. Either they're choosing to ignore them or playing the blame game.

I would also note that successive people over the years have been blamed as the cause for disturbance and jumped (or pushed) out of the project. And yet miraculously nothing seems to change when they leave.

There is a fundamentally toxic mindset, deep rooted in the organisation behind this project. No-one wants SMF to fail, yet it would appear to be doing so in spite of that. Look back over the last three years. What has remained constant in that time, when the atmosphere was so unpalatable that devs threatened to withdraw their code? (Now, of course, you just have the problem of replacing those people.)

I do agree whole heartidly that it is sometimes excruciatingly difficult to get something moving around here. No doubt.

Then ask yourself why that is. Big corporations are slow to get things moving, because it takes people to figure something out, then it has to be run by the management, the more senior management, the risk people, the legal people, etc. That is the nature of big business.

SM is not an entity with that infrastructure. It does not have those constraints.

How come, then, that other projects of similar magnitude manage to get things done - when all the contributors are volunteers? What makes SMF different?

But... That's what happens when you're working with volunteers. People have lives. (At least, some of us *grin*)

Sufficiently motivated people make time for their passions. And there are quite a few sufficiently motivated people in this ecosystem. They just choose not to contribute to SMF itself. Ask yourself why that might be. I have spelled out my reasons. They appear to have consistencies with the reasons others choose not to contribute here.

I am glad to tell you it's not the correct assumption to make though. It is regrettably indeed an assumption, and it's too bad you think so negative about it. That's up to you, of course. But please, don't make the mistake of seeing that assumption as a immediate fact.

I call it as I see it, for better and for worse, and I'm prepared to justify why I call it that. The comments made by several project representatives do lead me to that feeling, but if you are saying it is incorrect, that's cool. I just want to see some evidence to back it up

The issue you are referring to was *not* an issue when the NPO was formed, or that is to say: Not in it's current form, it was handled differently at the time. Changes over the years however generated a new problem that was indeed not seen at first sight. And it pretty much isn't an issue anymore now though.

Actually, the issue I'm referring to was an issue at the time the NPO was formed. I will say it again: those people who signed CLAs did not sign over ownership of their code to SM. They signed a licence to allow SM to use it and be credited for it.

The use of CLAs should have prompted someone to talk to a lawyer about copyright and specifically who owns what. If you're going to get picky, technically even before the NPO held copyright it was an issue, since I know I and others signed a CLA for both the LLC and the NPO. But when the NPO took over and updated the copyright statement, that would have been an ideal time to consult a lawyer on the proper course of action. This should have been done prior to 2.0 final in 2011, ideally.

Just... Patience! (I'd almost add "young Padawan!" to that, but you're near officially OLD. No worries, you don't have to thank me for saying that. )

I'm nearly 30. In internet years that's frickin' ancient.

Even though indeed, the past is something to learn from and that's a good thing: better the process, better the environment. There have most certainly been some mistakes, some good things mistaken for mistakes and good things in a whole. It just strikes me that people in general usually solely focus on the negative instead of the good and the bad, and that on my part slightly annoys me heh.

From my perspective history just appears to be repeating itself. Different names, but the same general messages.

I'd love to hear what the good bits are.

Appearances can be deceiving, might I just note that. And you can ask anyone on the team to confirm that if you do not wish to take my word for it.

They can be, but they're the best evidence I have (and it's public, too). Though it is my understanding that there was actually a proposal to formally shelve smCore seeing how there's been no commits in several months. (Github reports 5 months since the last commit.)

I think that perhaps a whole fresh load of devs might prove to be a different situation than the same people being involved all the time. Fresh winds and bla.

It would be a different problem, certainly. But it would be a smaller problem than not having enough competent devs.

Duly noted: you, and probably more people, are in need of a status update on 2.1.
Granted, I do not think the developers will have any problems at all divulging that information and I would be very happy if people stepped up to help: it may speed things up!  Help is appreciated and it is what makes it community driven.

Me personally, makes no odds. I can always look at Github for the code. But it would certainly ease my concern over the stewardship of the project to see that someone's actively at the helm.

And yes, if there's some indication of where it's going, people are more likely to pitch in and do something. Even if it's only pitching in to beta test - if it's known that there are no new major features left to implement, you will get more people testing.

But sure, everyone could be disappointed, but it can go another way as well: sheer happines to be working on a still very much promising project. Past is past, and the past has given valueable lessons.

Only if the past is listened to and acted upon. I see a lot of the same frictions amongst people as I did back in 2010.

I'll take your word on XenForo, I don't know them.

There's been no release in a year, not even a patch of any kind, and the developers have been near enough inactive on the forum. The Internet Brands/XenForo lawsuit is hotting up, and they're in settlement talks on Wednesday. Whether they come to an agreement or not is neither known or clear. But it is our understanding that the XF team are actually flying out to California in person (previous settlement talks have been over the phone) for Wednesday, and it seems possible that XenForo will close as the result of settlement.

Well, in regards to SMF 2.1. I guess it's a matter of taste. And perhaps also a reason why you took the road of creating a fork.

I wonder how many people know the story. I also wonder how many people know that had the devs at the time not lied to him, SMF would have successfully recruited both of us for at least a year, if not longer, because he would have persuaded me to step up.

SMF 2.1 will be offering some splendid new functionality, rewritten parts, patched up current functionality, more in par with "today's world", et cetera. Is it a 100% new product? Nope. Does it *have* to be? Imho: Nope.

That's the thing. It's not on par with 'today's world', or at least it won't be on release. It'll be on par with 'today's world' - tomorrow. That's the unfortunate nature of slow burning development is that you will likely be robust but never up to date. You need to move very fast to keep up with current trends. To an extent it is not entirely a bad thing. But it is something to consider and weigh up very heavily.

You're free to be disappointed because you had hoped to see far more changes and a 100% new SMF product, but I have a opposite preference: I like SMF sticking to it's root in large lines but DOES take wishes of the community, and of course: self made up new functions, rewrites, etc, in mind with the upcomming SMF 2.1.

I never expected - or wanted - a 100% new product. That is the road to madness since then you have 100% new bugs to fix.

What bothers me is that we're 18 months on, after a 5 year cycle of development, with what might be called a public alpha. There are people legitimately concerned that SMF 2.1 won't come out this year or even the next given the history. This is what history teaches us - once bitten, twice shy and all that.

(My god, that whole part sounds horribly OMG MARKETING!!1! but it is my sincere personal opinion on the software.)

You wouldn't be doing your job if you weren't It's a completely valid point of view too. Keeping stability is important as well as adding new things. But not all forward development is adding new things, remember. It can be important to remove things too.

I mean, if you look at it that way: SMF 2.x wasn't a super huge change over SMF 1.x either: SMF 2.x also remained true to it's roots set out in SMF 1.x. Did it come with new functionality, a new design, large rewritten parts: Absolutely. But in essence, SMF is still SMF. The same is happening with SMF 2.1. Although, I ofcourse must admit SMF 2.x did have some *major* code differences over 1.x. (That is NOT to say that 2.1 doesn't have that. But, perhaps less than what you personally had hoped for. Which is probably another reason why you chose to make a rewrite of your own.)

When Wedge started, SMF 2.0 was still in RC - shortly before RC4 if memory serves. We set out almost a year before SMF 2.0 went gold. We were genuinely concerned that SMF 2.0 would be the end of the SMF line. We are still concerned that its long term health is not assured. We believe our concerns are well founded. But we'd love to be proven wrong.

Perhaps it could have been done faster, perhaps it could not have been. We had a few setbacks.
But... SMF 2.1 is getting closer to a release each day that passes. And that is a prime example of what I see as a good thing.

Yes, but what next? I remember full well that 2.1 wasn't even supposed to be developed. It was only ever intended by those who started it in motion as a stop gap, though it has gone beyond that in the intervening months.

This is where a roadmap can be important.

Yeah, you can certainly argue it's taken it's damn time... But you can also look on the bright side of life (yep, that was a reference.) and focus on happy thoughts: It's getting closer to RC status day by day.

Happy thoughts won't move mountains, only hard work. I have to say, I'm enthused that at least someone cares and is passionate about it, but right now it's talk. Show me something.

The other problem is that we'll never know how many people are thinking the same things I am.

I really want SMF to succeed because I want to see where it goes in the future differently to Wedge, to ElkArte, etc. I want to see where the paths lead, we all started from the same place and we're going in different directions. But as I've said, I can't in good conscience step up too much in terms of contribution to SMF, because it wouldn't be fair to Wedge. But I do occasionally share some of the things I've learned, and it's nice to see some of the things SMF and ElkArte have learned then gets shared with us. There *is* co-operation going on, but it's hard work.

You know me by now. I'm not really one for talking so much. I get down and get my hands dirty with the best of them. I dislike bureaucracy, and meetings and talking about things. Doing them is much more fun, most of the time.

You're asking to receive a basket full of cookies at once. There will be news.

COOKIE OM NOM NOM NOM

I want to share your optimism, it's infectious. But history taught me that I need to wait to see it before I'll believe the marketing hype.

[kat]

******... this is becoming something like a reasonable, sensible conversation between responsible adults!

My brain hurts...

One thing that I'd like to add, Arantor...

This "Transparency" thing is all to the well-and-good.

However, to the vast majority of people, what happens in the ol' team boards and all that stuff, is of little or no interest. They don't give a sh1t, as long as the software does something remotely similar to what they want it to do.

Sure, there are members, such as yourself, Nao and others, who might be curious about it, even if it's from a "Historical" perspective.

But, if I was just a normal member, whatever the Hell "Normal" is, I doubt I'd care, much.

We all, to a member, have different ideas about which direction(s) the future of SMF (The software) takes. As most know, I would've preferred SMF v2 never to have happened and for SMF v1 to have been expanded to include new features, if required, and other stuff.

But, I was probably in a minority of one, there, so SMF v2 came and did it's thang.

But, apart from the direction that the ol' software takes, do many, really, give a stuff about the rest of it?

I'd imagine that the vast majority would find it all tediously boring, to be honest.

[emanuele]

We all, to a member, have different ideas about which direction(s) the future of SMF (The software) takes. As most know, I would've preferred SMF v2 never to have happened and for SMF v1 to have been expanded to include new features, if required, and other stuff.

I would like to still use Lotus 123...does that make sense?
No.
Does SMF want to produce a software used by many or just by a couple of people on the team?
Sorry, if it sounds harsh, but that's the truth.
And that said, the differences between 1.x and 2.0 are not *that* big in terms of code (proven by the fact that they still share several  bugs). Yes, there are changes, I'm not saying they are exactly the same, though are not *so* different (if 1.1 is win2k, then 2.0 can be the equivalent of winXP).

But, apart from the direction that the ol' software takes, do many, really, give a stuff about the rest of it?

The problem is exactly that.
Make a second account, without team access, take a look around and tell me where you can find any (relevant and up-to-date) information about where the project is going.

[kat]

Is that one of the things that the PM should be doing, perhaps?

[Kindred]

the PM and the marketing group... yup

[emanuele]

TBH it should not be something born from nowhere and "imposed" on the community, it's not a "procedure", it's something that you have to cultivate, day by day, listen to the community, work with them, make them feel part of the project.
Open development is not just put the repository at github and wait. If you really aim to open development the last thing you have to do is close yourself in the ivory tower and "take decisions".

Unfortunately I always see procedures and delegation (e.g. "it should be the PM") here around, instead of actually stand up and do something.

[Kindred]

well, you are both right and wrong...

this is not "delegation".   This is something that SHOULD be ongoing and SHOULD be coming from the PM and/or Marketing. After all...   project status and reports is part of the job.  So, it's not delegation... but you are right, the PM should gather the information and then stand up and do it....

Also, I am uncertain what you mean by "imposed" or "procedure" or even "take decisions".
Keeping people informed on the status of the project was always intended to be the job of the PM and Marketing.

[Arantor]

One thing that I'd like to add, Arantor...

This "Transparency" thing is all to the well-and-good.

However, to the vast majority of people, what happens in the ol' team boards and all that stuff, is of little or no interest. They don't give a sh1t, as long as the software does something remotely similar to what they want it to do.

Firstly, if there are more transparency (I'm not saying *total* transparency, just *more*), it might make people realise that 1) the team is supposed to be part of the community, not by and large superior to it (my interpretation), 2) the team's self-imposed role is serving the community and 3) that for the project to survive, it needs to talk to the users.

How many people, other than the team, have any real input from the community? The devs have done a fine job but I don't see anywhere that the team invite specific discussion about features with the community. Involve the community. We do it, it really isn't that hard.

We all, to a member, have different ideas about which direction(s) the future of SMF (The software) takes. As most know, I would've preferred SMF v2 never to have happened and for SMF v1 to have been expanded to include new features, if required, and other stuff.

2.0 is *exactly* what that is. It is 1.1 with lots and lots of extra features. Only one thing could have been called to be 'removed' from 1.1, and that was replaced with something else that serves some sites better than what 1.1 had, and some worse. (I refer to permissions by board vs permission profiles.) But nothing else was actually *removed* from 1.1 in 2.0.

But, I was probably in a minority of one, there, so SMF v2 came and did it's thang.

But, apart from the direction that the ol' software takes, do many, really, give a stuff about the rest of it?

No, of course they don't. But that's not the point.

The point is, for an organisation that promised openness after so many years of being closed, the openness still appears to be mostly in name only.

No-one wants to contribute to a journey that they don't know where it's going.

I would like to still use Lotus 123...does that make sense?
No.

Lotus 1-2-3 was awesome in its own way. I miss it.

Does SMF want to produce a software used by many or just by a couple of people on the team?
Sorry, if it sounds harsh, but that's the truth.

It has seemed to me for a very long time that those who control the project have more say in what happens in the future than those who build it.

And that said, the differences between 1.x and 2.0 are not *that* big in terms of code (proven by the fact that they still share several  bugs). Yes, there are changes, I'm not saying they are exactly the same, though are not *so* different (if 1.1 is win2k, then 2.0 can be the equivalent of winXP).

Yup. Better explanation than mine, too. 1.1 and 2.0 are not so different.

The problem is exactly that.
Make a second account, without team access, take a look around and tell me where you can find any (relevant and up-to-date) information about where the project is going.

And we're back to a lack of transparency. The only place you can find anything like that out is by scouring Github, and not everyone wants to start off with that.

Is that one of the things that the PM should be doing, perhaps?

the PM and the marketing group... yup

Hmm. This seems wrong somehow.

TBH it should not be something born from nowhere and "imposed" on the community, it's not a "procedure", it's something that you have to cultivate, day by day, listen to the community, work with them, make them feel part of the project.

And they wonder why they can't recruit and retain developers.

Open development is not just put the repository at github and wait. If you really aim to open development the last thing you have to do is close yourself in the ivory tower and "take decisions".

Openness by name, closedness by execution.

Unfortunately I always see procedures and delegation (e.g. "it should be the PM") here around, instead of actually stand up and do something.

I have been accused of causing trouble around here. But this is why I do what I do - because I will not just sit around and do nothing hoping that those who are 'delegated' the authority to act will do so.

this is not "delegation".   This is something that SHOULD be ongoing and SHOULD be coming from the PM and/or Marketing. After all...   project status and reports is part of the job.  So, it's not delegation... but you are right, the PM should gather the information and then stand up and do it....

Then there is a systemic failure on the part of those groups.

Also, I am uncertain what you mean by "imposed" or "procedure" or even "take decisions".
Keeping people informed on the status of the project was always intended to be the job of the PM and Marketing.

So please explain to me why we haven't seen anything from these people in months? The last update I can find from a non dev is in this board and dates from September 2012. Everything else has come from the devs themselves.

If these people are supposed to do a job, bloody well get on and do it. If not, don't interfere with those who are, i.e. the devs.

Btw, you should see Norv's dismantling of the copyright mess on ElkArte. That's some serious reading - and I thought I had a chip on my shoulder about SMF's mishandling of things.

[Kindred]

It has seemed to me for a very long time that those who control the project have more say in what happens in the future than those who build it.

Complete and total BS, Arantor.   We had this dicussion elsewhere, and you keep harping on this, veen though you are STILL, as pointed out before, mistaken..
No one on ANY team has ever tried to tell the developers what to code or how to code it.
The **ONLY** "interference" in supposed development "powers" came over the approval to actually MAKE a release. The dev team has always had total control over what happens in the future of the project, despite mine and other's best efforts to try and get them to accept input from the other team members (and I will note here, emanuele and spuds DID take input for 2.1, so this is not directed at them at all).



As for Norv, I've heard from others and, as far as I can tell, she is has become delusional. Given her past attitude and actions, I have no respect left for her... and that's all I'll say on the matter.


As for doing the job...   Yes. they need to get on with it. And for the last bloody, f'ing time... no one is interfering with the devs.

[Arantor]

Complete and total BS, Arantor.   We had this dicussion elsewhere, and you keep harping on this, veen though you are STILL, as pointed out before, mistaken..

Actually, I'm not. Go read Norv's commentary on the copyright, maybe you'll understand. But I doubt it.

The dev team has always had total control over what happens in the future of the project, despite mine and other's best efforts to try and get them to accept input from the other team members (and I will note here, emanuele and spuds DID take input for 2.1, so this is not directed at them at all).

So in the first sentence you say that no-one has ever tried to tell the developers what to do. And in the second sentence you say that you had to get them to do something. Make your mind up.

As for Norv, I've heard from others and, as far as I can tell, she is has become delusional. Given her past attitude and actions, I have no respect left for her... and that's all I'll say on the matter.

I disagree. In particular I would encourage anyone to read http://www.elkarte.net/index.php?topic=162.msg1272#msg1272

As for doing the job...   Yes. they need to get on with it. And for the last bloody, f'ing time... no one is interfering with the devs.

You're so, so wrong with that statement.

I look at what Wedge and Elkarte are doing and I cannot conceive in my wildest imagination that SMF would ever do any of the things that either project are doing. Not 'that they would do' but things they are doing.

For example, I know full well that if I'd ever suggested the plans I had for Wedge's plugin manager for SMF, you would have shot them down out of hand, as you have even on Wedge's own forum. Never mind the arguments I presented for its defence, never mind the hassle it would save, but it limits flexibility and so you'd shout it down if it were to be suggested here.

Is that not interference? Would that not be curtailing what I as a developer feel is appropriate to be added to the base software?

Not all interference is blatant. Not all of it is public or even semi public. The fact that you're still denying it means you've convinced yourself it isn't happening, even when successive groups of people are all saying the same thing.

[Kindred]

no..  you have misread.

The dev team has always had total control over what happens in the future of the project, despite mine and other's best efforts to try and get them to accept input from the other team members (and I will note here, emanuele and spuds DID take input for 2.1, so this is not directed at them at all).

So in the first sentence you say that no-one has ever tried to tell the developers what to do. And in the second sentence you say that you had to get them to do something. Make your mind up.

I said that we have TRIED to get devs to accept input. That is different from telling them what to do.

I skimmed that crap from Norv. I understand what she is trying to say, but I disagree and I still say that she is full of it.
And regardless of what Norv claims, no one has ever told the devs what to code or how to code it. EVER!

Finally, I did not shout down your plugin deisgn.
I commented that I feel that SMF's deisgn to allow editing of source files is one of the things that makes it more powerful than a straight forward plugin. I think that plugin designs are useful, especially for the generic user... I think that the SMF package manager should exourage plugin but support both.   However, I never shouted your concept down and my comments are expressing my considered and expereinced position.

And this is the attitude that bothers me.
You say "devs should consider and accept input form the community members"
then you turn around and berate me for saying "devs should accept input from the team members"

So, what you are really saying is "Devs should be the king of all they survey. They should be able to do anything they want, without consideration to anyone else and they basically are the only ones that matter, ever."

That's the attitude that hurts when you have a mature product that has a much wider team than just "the developers".

Wedge and Elkarte can do that, because they are not actually a real product yet.
They have no distribution (outside of some testing) they have no community to support and no need for a team to distribute, document and support the product. Anything you have in the way of community, actually, is "borrowed" from SMF due to the fact that both projects are offshoots.  If you were coding from scratch, I don't think you'd have more than a few members for curiosity and testing.
This is not to denigrate anything you have done. I've looked at wedge. It's cool. You and Nao have done an amazing job.
Your entire community is piggybacking on the previous and current success of SMF, though.

[Arantor]

I did not shout down your plugin deisgn.
I commented that I feel that SMF's deisgn to allow editing of source files is one of the things that makes it more powerful than a straight forward plugin. I think that plugin designs are useful, especially for the generic user... I think that the SMF package manager should exourage plugin but support both.   However, I never shouted your concept down and my comments are expressing my considered and expereinced position.

Actually, you did. I put forward all of my points - and there's even more that you didn't even consider, like security - and that was all dismissed because it's not as flexible as SMF, and no amount of persuasion would have changed that fact. Had I tried to implement it in SMF, you'd have screamed about it.

And this is the attitude that bothers me.
You say "devs should consider and accept input form the community members"
then you turn around and berate me for saying "devs should accept input from the team members"

Correct. The fact you don't understand what's wrong with this is one of the key points of what's wrong with SMF.

Why are team members more special than community members? Are they more special than community members? If so, why?

More importantly, why should devs 'accept' input from team members? They should consider it, but no more or less than any other community member. This is the part that a lot of team members have trouble with.

We're the ones at the rock face, not you. If you're going to 'suggest' something, either do it at the same level as everyone else, or get down and dirty and pitch in. This is where it's gone wrong: the team feel they are better than regular community members at knowing the direction of the software - and that's wrong.

Go take a look at Wedge and what we do. We involve the community. We suggest things and get the community's take on it. We are not just the leaders of the community, we're *part* of the community. Something the team here generally cannot stand up and say. Some members can, yes. But the majority cannot legitimately make that claim.

So, what you are really saying is "Devs should be the king of all they sruvey. They should be able to do anything they want, without consideration to anyone else and they basically are the only ones that matter, ever."

That's the attitude that hurts when you have a mature product that has a much wider team than just "the developers".

In a community built around a piece of software, that's not entirely an unfair statement.

Here's the $64,000 question. WHY does it hurt? You didn't build it. You don't own it. Why do you have attachments of emotional value to something you didn't build?

But it's also a biased statement from someone who cannot see it from our point of view. We do try to consider everyone else. The fact anything gets built at all is proof of that small fact.

Wedge and Elkarte can do that, because they are not actually a real product yet.

You have a funny definition of 'real product'. We've released alphas that are installable. That qualifies as a 'real product'. It also shows your arrogance a little.

They have no distribution (outside of some testing) they have no community to support and no need for a team to distribute, document and support the product. Anything you have in the way of community, actually, is "borrowed" from SMF due to the fact that both projects are offshoots.

Oh, enough of the snooty down the nose already.

This is not to denigrate anything you have done. I've looked at wedge. It's cool. You and Nao have done an amazing job.

Please do not mistake me for a fool. The previous statements fairly clearly indicate that you consider us both to be toy projects, whether you want to admit it or not.

Both projects have made more progress since their inceptions than SMF has in the same time. What does that tell you?

Your entire community is piggybacking on the previous and current success of SMF, though.

Previous, yes. Current? No. It's growing because of the *lack* of current SMF success and apparent stagnation of the project.


I would carry on arguing but I appear to be the only one who actually cares enough to fight the good fight. Everyone else relevant in this matter already moved on, because they've already given up on SMF's future. I'm one of the few people who was involved but who cares enough to spend any effort on hashing this stuff out. But I feel like I'm wasting my time because the people who need to change aren't listening and are being drowned out by people who think they're acting for the best but really making it worse.

[kat]

The transparency thing is something that we're all gonna have different ideas about, innit?

I'm afraid that I can only see that from the side of the fence that I'm sitting on and it's not something that's ever bothered me, to be honest.

As long as people say exactly what they're thinking, I'm OK with things. As long as people read things in the way that the poster meant them to be read, everything would be fine, really. Pity we can't do that, very well, coz certain nuances are always gonna be missing.

Tiz a shame, coz I feel that a good proportion of the brown stuff that's hit the ol' whirly thing, over the years, could've been avoided.

[Kindred]

Arantor, I no way was my post meant to be snooty and you, clearly, alreayd decided what I was saying without actually considering it.   Way to slant what typed into something that I didn't actually say.

I don't consider you a "toy" project. I do consider wedge to be a kick-off project that has no large community or need for a lrage amount of community support.
and "real product" means that, yes, you have an alpha... but it was a limited release to a select few. You do not have widespread distribution and you do not have a need to support thousands of people using your software.

You DO NOT try to "consider everyone else" (you, being devs in general, not you specifically).
Based on what you have said, you (and this is the direct you)actually believe that the team members should have **LESS** input than the community.

As for why devs should accept input from team members? Well maybe because we're all on the same team and all have invested ALOT into SMF. With the exception of you... I would guess that I have probably put as much time into providing support and other "background" stuff for SMF as any developer has spent on coding, in recent years (unknown and the other early developers are excluded in that comparison).  You're right... I didn't code anything. That's why I don't tell the developers how to code. However, even if the team does not actually put code in, the devs should accept input form them, since we're all a team and the others are the ones who have to support and document what the devs code. Also, those who make it onto the team have established that they have a fair amount of experience with SMF and probably have some good input.
(note: nowhere did I say that the devs have to DO what the team says, I said that they should accept INPUT from the team)
This is where you (and the others) seem to have a falling down stroke and blind-spot. input != command.

finally

Both projects have made more progress since their inceptions than SMF has in the same time. What does that tell you?

It tells me that they are being coded by folks who don't have to consider the larger picture. Who don't have to support several thousand existing users.   You can definitely get a lot done that way... until suddenly you make a full release and are more busy providing support than you are coding. (much of the time that you spent coding wedge, you also spent AWAY from here... not a criticism, just an observation)
Norv tried to do the same with SMC... (and I will note, there was **NO** "interference" from anyone with whatever the hell they thought they were doing over there) and then she flaked, Guess she's just not as dedicated as you.

[All Colours Sam]

but I appear to be the only one who actually cares enough to fight the good fight

I'm still around but every time I open my mouth, everyone else puts on the "oh no, she again... more drama" chip before actually listen to my words.  Besides, all the things said here has already been told elsewhere, it is so damn easy to attract new devs or at least show signs of movement... how many time has passed since the license change and 90% of the PHP community out there still doesn't know that SMF is now a truly open source software... unbelievable...

Do I still care, yes I do.
Does it hurt to see absolutely no signs of movement here? yes it does. The only "changes" I saw so far is Joshua been a dev now and the "open source" title next to the "Simple Machines Forum - Free" text in the <title> HTML tag. both of them are just cosmetic changes since Joshua has always been involved with development even though he only pops out from time to time.

As a plain mortal with no team access, I have no idea what are the plans for future SMF development. I have plans to take a look and re-factor the dump database feature but how am I suppose to start with it if I have absolutely no idea on whats next after 2.1?

I still has the (now vague) idea on refactoring the modsite here but how can I even suggest things when the team just sits there on their shell just waiting for stuff to happen?