ElkArte Community

I believe people should know, what happens on simplemachines.org. I believe I owe everyone informations they must have, to make their decisions.

Allow me to make this thread, as a collection of facts, and my perspective over them.

SMF status

There are thousands of sites who depend on SMF on simplemachines.org, from security updates, new releases, packages, everything served to users from it. The community has started to wonder about what happens with SMF, again. They're right. And people need to know.

The past few months, there is basically no active development in SMF.
There is no one left, with both experience, access and will to make a release.
There is only one developer able to make releases, and through his dedication it's still possible. He has to rely on one other person, to painfully synchronize somehow to push out even for the latest security patches.

There is no one really handling the sites, subsites installations, wiki, downloads. They're outdated, sometimes even for security and/or needs of people who work on the project. Persistent and worsening infrastructure problems. I said elsewhere that it's crumbling. Because it is.


When people try to help, they may or may not be able to. Because there are only very few - one/two - who control access to sites, servers, FTP accounts. And they refuse to hand over access people need... by criteria that have nothing to do with expertise, will, or anything... In time, a network of red tape has been built to excuse their choices... and I'm afraid they don't even see, how it's only hurting the project.

I'm sorry, but it's just how it is. And I am concerned, I admit. Thousands of people relying on SMF need to know and have the right to know, to make their own informed decisions.

2010-2012, summary notes

Since 2010,
Around seven out of nine developers and development contributors have left SMF, for different reasons than RL reasons. Only a couple for RL reasons.
Around seven out of nine. Both developers and any significant help closely on it or around it. Those only ones who have stepped up since 2010 and have worked hard on significant responsibilities. They are no longer there, and not exactly for RL reasons. Some pushed out, some from a cascade effect of the lack of perspective and impossibility to move forward, some combined reasons with disappointment with management and giving RL time.

Today, there is no active development in SMF. For the past few months.
Until November 2012, ~200+ commits / month.
Last few months,       < 40 commits / month.

Developers have left, and are rebuilding this project on fresh bases. That is another matter, though, not the point here.

---

I have taken responsibility for SMF in 2010. Myself, I had root access to almost all servers, admin to sites and all. It enabled me to make sure the project can still work normally, albeit sometimes at the edge. It enabled me to make sure to step in when people needed something, information or access, and almost no one else even knew what is happening and needed, such as for customization and all. Apart from software development and related.
I believe I didn't do my job too well. On the other hand, I admit I also believe... that I shouldn't have withdrawn... because it was, well, quite clear, that when I do, the few in SM management/infrastructure were not going to give by far any more access to others. (among other issues)
The route was going to be, towards locking development, site, any movement forward of significance. Incessant blocks, refusals, ...false "reasonings", ...personal feelings and choices, were going to be too much for anyone to handle. And ultimately suffocate this project.

I'm sorry. I have to admit, despite the tone (not entirely avoidable, it's simply true), that I'm not exactly blaming a certain person or another... If anyone is to blame in the big picture, that is myself, not them. It just.. wasn't possible for me to stay either, when I knew I wasn't able to fix this project.

---

In 2010, and after, I always told people that this project is badly wounded, and we can try to work to heal it... But there was a moment I was sure it wasn't true: it had cancer, and, ... you can't heal cancer.

Today, it's just doing it over again.
It was going to make a LLC in NPO dressing.
Have only a couple people with 'power' and controlling everything through access to resources.
Push out developers, at an accelerated pace even.
Have some manager who has to get his way... war after war, game after game, while the project was breaking in front of people's eyes. It never stops, in poor ole' SMF.

It isn't really about people. There are a few people I cannot work with, true, and part of the reason why I was going to withdraw. But that's not really it, in the big picture. It was a movement which became unstoppable after a moment (not sure which was the cornerstone, early 2012 in a way for me, but probably 2010 entrenchment itself, if not earlier, depends how you look at it).

SMF was in an unstoppable movement down... towards a 'corporation' which was going to kill development. And, it did.

---

The past few months, since most development stopped, the situation has worsened quite quickly.
(if I am wrong somewhere and you can correct my words, please do. The following are shocking, but true.)

The SM NPO 'corporation' was supposed to handle resources on behalf of the project.
Instead, the management was going to tell, in plain words, recently, to the SMF team, that they don't.
That SM is the "owner", the corporation who "owns" resources, servers, sites, and they "decide" what SMF needs.

That SMF team is not allowed to make a vote of non-confidence in 'the corporation', and let the project free or take it elsewhere, under an organization capable to handle it. The SM manager (and "father") told them the freedom of choice of SMF wasn't in his organizational diagrams. That SM owns the project... and only they can "decide".

That SM is more important, and (ok, this is difficult for me to write but I have to)
... that, to them, there are heavier consequences if SM dies, than if SMF dies...

I'll start with details for your knowledge, on the so-called 'copyright issue', since it's simple, essential and currently in an ... unbelievable stage.

The 'Copyright Issue' - summary
Copyright is a set of exclusive rights given by the law to the author of a work of authorship.
When you create a work - or add to a work - you automatically receive these rights, and you can grant any of them under any conditions, through a license, to anyone.
Copyright holders of SMF software are its developers and contributors.
The software belongs to those who do the work of authorship. And they share it to the world, giving equal rights to everyone, by only licensing it with an open license. It's that simple.

SM corporation is a licensee under BSD 3-clause license. Or MPL, for a few projects/pieces.
IBM corporation is a licensee under BSD 3-clause license. Or MPL, for a few projects/pieces.
Everyone receiving the work, the releases, the code, is a licensee under BSD 3-clause license. Or any other open license.

Developers - including community contributors alike - share the software under a license.
SM corporation has received the rights given by the BSD 3-clause license, and should respect its conditions:
never remove or alter the copyright notices from the code.

---

SM is telling SMF community today... that they sit and "make decisions" on licensing. That they're self-entitled "authority" on licensing. 5-6 managers, non-contributors, sit in their private board and claim to "make decisions" on the software licensing. On the work that SMF developers and community have made available to the world under the license. They claim to remove notices, alter them...

But they forget this essential detail: licensees should respect the licenses granted to them.

The 'Copyright Issue' - history

In May/June 2012, we have changed SM requirements for the projects under the umbrella, to require open licenses only, and replace CLAs with DCOs for software, simple agreement to the license for documentation, and a few others.

Immediately after, I have removed CLAs from the SMF development policy on licensing/copyright. For bigger projects, I have replaced them with DCOs, for others not even that.
I set the development policy on licensing/copyright to:
 

• require open licenses alone,
• under DCO sign-off where applicable.

Nothing else. You can find it documented in each of the repositories, there are topics, explanations.

Your work, your code, design, were created by you and licensed by you, to everyone - to the world - under the BSD 3-clause license.
To SM Corporation, to IBM Corporation, to people too, to your peers, to your users, equally.
No one has more rights than everyone else.

Meaning: After we changed to DCO/nothing else required, SM corporation has no more privileged position, no more rights than everyone else - as before they had extra-rights through CLAs. SM corporation has no "copyright". Just like IBM corporation doesn't.

---

Spuds and Emanuele have moved SMF forward, through their work, their dedication, their time. And they have kept it shared with the community. By their work in the open, on github repositories. By blogs too (a small start, meant to bring information too on their goals and status).

Months later, I have checked the repositories, made some fixes, made some code reviews. Developers had worked very hard, to fix and improve the codebase. People had started to contribute, community contributors, with no badges and no 'roles' and stuff, have added their work to make the software better.

And I have acknowledged their work, and the community contributions, by changing the copyright notice to SMF main codebase, to:
"@copyright SMF contributors".

In the open, under the development policies for licensing/copyright in SMF I had left in place.

We have noted the change in a development blog, with a link to the change, on github, and we have invited the community to feedback. We have told the community that it might seem like a small change, but the thing is, it's their work that drives the project forward, their choice, their responsibility.

Developers have given the project to its community. They wanted it that way. And I definitely wanted it that way.

---

Sorry to say... but SM corporation wanted something else. They have removed my discussion with them, from SMF Friends and other groups view.
And a few people - current SM speakers - have started a war.., in very private environments (7-25 people boards):
That "The Corporation must own copyright!".
That "Developers must assign copyright to the corporation!". (seriously? "Must"?)
That "Developers code for the corporation, so they assign copyright to the corporation!!" (...huh?)

I don't know what they were thinking, but... it's hard to describe publicly, no matter how much I'd try.
I'll just say, incessantly pushed developers around, to force their hand, to accept, that the SM corporation "must" hold copyright over their own work*. To give them copyright, some extra-right, than they gave by the license, for their *own work...

Developers have left, and Spuds has forked the project.

---

Code for the corporation benefit. For the benefit of a closed privileged group. Whatever they were thinking, I know one thing... There it was: it's always dangerous to give copyright/licensing rights to those who do not deserve your trust.

The "Copyright Issue" - follow-up

They have jumped on the repositories, and removed my acknowledgement notice from the software. Not that I mind objections or changes - I'm not too happy with my own PR anyway, but that's not the point.
But the "authority" has bypassed the open development process, including SMF's process on copyright/licensing updates I had set in place.
And, within the next weeks, SM corporation has taken control of the project.

All rest aside, I'm afraid they still did forget. That they're a licensee.

And licensees should respect the license: never remove or alter the copyright notices for the software granted to them by developers/contributors.
Licensees are not an authority on copyright/licensing. That's meaningless.


As lead developer of SMF, I have made all licensing changes or adjustments (and in two cases I believe, oversaw others) to any piece of official software. I have an interest in copyright/licensing, it's true, but that's not only it: developers should pay attention to licensing, since it's simply fair. To respect licenses when they integrate code from other projects, to verify and to adjust licenses appropriately when the project receives code from pull requests, to make sure that code is properly licensed and any mistakes are fixed.
Of course, they may need help on that - the more, the better, and there is great help out there. But help means help. Sorry to say, but some corporate management, non-contributors, non-developers, removing license notices at their whim, then sitting in 7-people private environment to "make decisions" on licensing is not help. It's an attempt to control the SMF development community, and this one is quite screwed up at that: control over your own work conditions from a handful of non-contributors.

I'm looking on sm.org today, and I find it unbelievable... and unacceptable. They keep the entire SMF community blocked, over their so-called "decisions", for months.
It's not a joke. It's SMF development community under SM corporate control today.

If someone, some entity, had more rights (licensing/copyright), it's a dangerous power. And unacceptable for them to use them blindly, against your will.
But in this case, it's even worse. That's exactly what SM NPO are not supposed to do at all.

Licensees do not "make decisions" on licenses granted to them. They only respect them.

The "Copyright Issue" - status

I look at sm.org...

On one side,
     They have forced SMF developers hand, to "give give give copyright to the SM corporation". Under DCO.
Developers told them there is only a license. Over the distribution, over the software, over any work. The authors' work.
They weren't satisfied. They pushed developers to a wall, to accept, that they 'give copyright' to the 'corporation', over their own work...

On another side,
     I think (I can't know for sure), SM BoD are asking SFLC, about the little notices.
They're giving them an image, in the name of developers, on our intentions when I set up the DCO-based policy. You see, they withdrew the former 'corporate editors' claim. Now I think they're giving an image, about developers intentions with the DCO-based policy, and they're still asking for advice about the notices.

On yet another side,
     They're innocently telling former developers or wedge developers, that... they're 'only protecting copyright'. And it's a 'legal legal matter'. That 'legally legally' they hold standing in court for copyright infringement. With a simple licensee status.

On yet another side,
     They're keeping the community at bay, to sit and wait until they "make decisions" on licensing. Telling an entire community, that the "legal legal entity" makes "legal legal decisions". Over community contributions... That they're privileged, you see... everyone else must respect each other's license (=the license of the pool of software in the repository), but they claim... they have the authority to disrespect licenses.


It's unbelievable... but true. They're playing a game, sorry to say, with everyone. With... everyone.

A game of power and control over what was supposed to be a community driven project.

https://github.com/SimpleMachines/SMF2.1/pull/386 yet another perfect example to kick (former) developers bootylicous.. more than 90% of the SMF codebase is from former DEVs  ;)

I had already submitted the correction to the PR creator:
https://github.com/ziycon/SMF2.1/pull/1

SM "Corporation" has removed developers copyrights from the code, claiming shamelessly that they had an "understanding" over their own work.
Now they're on to remove credits. There's a continuous mentality that badges are the "reason" and "enough" for crediting the work. (and Arantor was still wondering elsewhere how come those who don't do the work think they're privileged by default...).

Please do note, I cannot and do not blame the people. And I would surely not "blame" new team members over there, where there are no developers to guide them.
It's just that, as "SM/SMF" (under this name) is spiraling down, how many of these will still happen.

Waste of time :(

Translation of the announcement "Copyright changes" (http://www.simplemachines.org/community/index.php?topic=504840), of SM corporation.
Fair warning: this won't be a nice 'n cozy post. Take it or don't read it.

---

Dear valued community,
(our Marketing department came up with this.)

As you may be aware, there has been debate recently about the copyright line that is used in the SMF code.
As in, the last SMF developers refused to give us copyright over their work (and thereby community contributors too), so we warped at it for months, over and over, until we land-grabbed it somehow.

Although it has taken quite some time, we wanted to be sure that there is no one left, who might've tried to do the right thing for a change.
The changes will be positive for contributors, as long as they work for the corporation, as in, they're work-for-hire-for-free.
And wouldn't break the understanding that they had with our Corporation over their code contributions.
Of course, we had no "understanding" other than granting us an open license under DCO-or-nothing policy, but who cares. We told our lawyers we had an "understanding" with them, and screw them if they said no.

After extensive debate (between 3-7 managers, non-code contributors, of which 3 inactive), and reviewing with experienced lawyers (whom we messed around as much as we could, to think we almost failed! but we changed our tune in time), we will be making the following changes starting with the 2.1 release.
Of course, we kicked developers out in the meantime, and there will not be a 2.1 release, but we wouldn't lie to you, would we?

The copyright lines in the top of the files will change from:
@copyright YEAR Simple Machines Forum contributors
Wait, no, lets cover up the acknowledgement of righful copyright holders, lets go back to... where was it, the older and inaccurate one...
so, there we go, from:
@copyright YEAR Simple Machines
to:
@copyright YEAR Simple Machines and individual contributors

Code contributors will be listed in a special plain text file to make it easy to see. The credits page inside the software will still remain.
We'll only remove from it almost all developers of SMF (https://github.com/ziycon/SMF2.1/commit/46f08685c29c47cdc6177949db421badfbd2ac40#L0L561) as you know it. Really.
After all, they're only some SMF Friends, so no one needs to know their names. Even, some refuse to hold any badge on simplemachines.org. Which means meh, we can disrespect their work as much as we can. And once we did that, of course we're doing the same for people who have supported this project for years, and so on.

The copyright line at the bottom of forums will remain unchanged.
Well, this is an useless statement, since the license allows to change it anyway, but we live and breath in a proprietary/corporate culture, and therefore feel the need to say it.

The changes we are making will give more credit where it's due.
We do that by removing from credits Compuart, Grudge, Thantos, Bloc, Aaron, some small and irrelevant contributors to this project like that.

And also clearly states that individual code contributors hold copyright to their submitted work, while still allowing Simple Machines to use it as part of the Simple Machines Forum software.
Well, Norv has explained to us over and over, that the BSD 3-clause license allows us to use it freely, share and reshare at our will, just like anyone else, as long as we respect the license they have granted to us and everyone else. But! We are not content to be like everyone, we must have moar, we must land-grab ourselves the right to disrespect their license.

Simple Machines holds copyright over the collective work that is the Simple Machines Forum (SMF) software.
Well, no, it does not, but psst: that's what we told our lawyers we had a mysterious "understanding" about, with developers and community contributors. Y'know, a so-called "understanding" you're too stupid you know you had, over your own work.
Lemme tell you what that means: it means Simple Machines corporate members don't need to lift a finger, and poof:
 - they have the same rights as those who have actually made this software,
 - and more rights than SMF Friends, translators, beta testers, some stupid "individuals", anyone else in the community.
You only have to be a corporate/team member, to hold the "position of power" we wanted so badly. (psst: it allows us to be entitled to CheezWhiz anyone everytime when someone who doesn't do the work has an "opinion" about how those who do must do their way. Finally, damn it, finally we stamp off our entitlement. Norv was certain it'd kill any chance in hell of the project, no matter how unlikely or narrow, so removed it from us, but we're land-grabbing it back. Hah, take that.)

If you're just a user of our software, none of these changes will have any effect on your use of SMF. Except for some small and insignificant details, like your forum security and maintenance, 'cause we made sure in the meantime no developers can possibly even make a patch when they consider it necessary. Let alone move this project forward. But don't you worry, the future is bright, under the NPO we turned into our corporate playground.
If you're a developer or contributor, nothing fundamental changes. Only, we have your understanding that you work for the benefit of our corporation, for our egos, as long as we like you. Then we push you out. Disrespect your license, remove your credits, block your access, fun like that.

...in how you can use the code as long as you make the above changes to any SMF 2.1 code you are using. Well, the 2.1-only code was written in majority by those who told us 'No' and let Norv tell us 'No'. But we nailed those bastards, we threatened Norv with legal action for "copyright infringement of SM Corporation copyright" - wise move, innit?-. We made sure they understand, that if you contribute to "our" project, then you'd better expect legal threats and legal actions over your own work. And made them shut the heck up and just leave, while our BoD makes sure to lie to the community in their name.

We would like to thank the SFLC for their help and guidance in this matter.
Yep, well, we still forgot to tell SFLC a few things. For example, that developers kept telling us "No", and we kept yelling at them about lawyers and "legal legal matters" and "legal legal actions" over their own work of authorship.
And we missed to tell SFLC we had no freaking "understanding" of the kind. Instead, guess what: we simply told them that we did! Hah, smart move, don't you think?

Also, we want to thank everyone else who contributed advice and worked with us on this change.
Well, not that it'd be any. We didn't even listen to those whose work was in question, why bother, doh.

Thank you to the community for your patience in this matter. Also, thank you to all the contributors. We thank you by land-grabbing your work, and claim we made it: we, the handful of SM Board of Directors, who have never touched the code. We remove your copyright notices, we remove your credits.
Thank you to all our users. We thank you by leaving your sites with no developers to attend to this software. And with this said, we hurry inside, to make many more "rules and regulations" to correct any chance anyone would have, to maintain it properly, or even remotely the SMF as you knew it.

You help make this community thrive.
Or should we say, we helped make this project and its community die.
You see, we treat our community as any corporation treats users: by putting our own interests, our stakeholders egos, before your forums, your sites future, your security even, and hide the truth from you at that. Sure you understand, we're a Corporation, a privileged group, after all.
Developers would never allow it, but we fixed that part. We got rid of them: simple and effective.

---

It's truth, the truth hurts.

Sad part is that I don't really know any more what's really best to honour the licences and contributors and whatnot. It's clear that they don't know what the right thing is and wouldn't if it bit them on the plumbers crack. Thing is, that announcement affects us too...

 * @name      ElkArte Forum
 * @copyright ElkArte Forum contributors
 * @license   BSD http://opensource.org/licenses/BSD-3-Clause
 *
 * This software is a derived product, based on:
 *
 * Simple Machines Forum (SMF)
 * copyright:	2011 Simple Machines (http://www.simplemachines.org)
 * license:	BSD, See included LICENSE.TXT for terms and conditions.

You're based on 2.1 code, yes? That would imply you needing to update to indicate so :/

As much as I don't entirely feel it's right, we dropped the dual header aspect, so each file (including ones that have absolutely no originating-from-SMF code in it) has:

 * @package wedge
 * @copyright 2010-2013 Wedgeward, wedge.org
 * @license http://wedge.org/license/

block in it, the license is a placeholder page until we figure out what actual licence we want (likely MPL2.0 unless we go paid, it's something we've talked a lot about doing), and there's a contributors file which lists all the things we've included and under what licence terms, in which we have:


And our credits page really goes to town on it:

That's all the people who were in the dev team credits in 2.0 which AFAIK covers everything up to 2.0. We explicitly do not list the 2.0 credit in every page, because I don't want to mislead people into thinking the licence is not what it is, if that makes sense.

I don't know that it's technically correct but at least we're trying. I'm sharing in the hopes that it encourages SMF to do the right thing. Foolish, I know, but it's illustrating the different ways to try and do the right thing.


FWIW, I can see their logic - warped as it is - in the credits: people who were in the credits for 1.1.x but not present in 2.1 development... should they be in the 2.1 credits? To them it seems perfectly logical that they should not be because they're not actively on the dev team at present. It's wrong but it does make some warped kind of sense.

/me still finds it amusing that he has code in 2.0.x but is merely on the Customizers list because that's the highest position he attained in the team in his time on it.


(Also: bug: this is in the quick reply, if I preview, I go to the full post screen with my preview but nothing in the post box!)

@Arantor,
I've been making a(nother) copyright/licensing re-review. Elk hasn't done that yet actually (except with some files).
I am still far too fuming, though. I have to choose coming back on it instead of a quick answer, sorry. But, if you wish, please see the WIP:
https://github.com/norv/elkarte/tree/copyright

License file:
https://github.com/norv/elkarte/blob/copyright/license.md
Example file:
https://github.com/norv/elkarte/blob/0105b64edfe74224a3ed5d96d782a26f853d5a98/SSI.php
Open to suggestions/objections - obviously. Others to be added.

If I may--
MPL 1.1, or MPL 2 with Exhibit B, which is essentially the same thing.
Until question #14 at the MPL FAQ (http://www.mozilla.org/MPL/2.0/FAQ.html) implies that MPL2, exhibit B or not, can't be suddenly turned entirely into a GPL product through a fork, I'd rather not take any chances.

https://github.com/SimpleMachines/SMF2.1/pull/433 was finally merged.. That's it, have to say "bye bye" to SMF. Requested account deletion over there...

It's now seven days ago and my account is still alive, they even seem to ignore my request for deletion..

In the past they have let most requests for deletion go for 30 days before fulfilling them. There's been some exceptions, but for the most part is has stuck to that.

TBH I've happened to ask, and I was told the team doesn't even know of TE's request. (or didn't.). Not to mention he didn't get an answer.

Also, sometime lately, a number of threads from 2009/2010 have been all moved out of SMF Friends view. Y'know... the LLC vs NPO issues.
Fun bit for you: I was just re-reading them, when they've been moved out of my view. At a refresh of a page. Purely coincidental, I reckon. :)

And, I understood that public topics from sm.org pointing to this thread have been removed.

I'd have to qualify the actions as closing in... in case it'd matter.

That's IMO a joke.. why should I wait 30 days? That's stupid. I'm finally done with SMF and the SM organisation and I'm sure not to return or to contribute code.. I've reactivated ny account, deleted my personal infos and marked for deletion again.
/me is tempted to write a small script in order to remove text and attachments from his old posts..

Account deletions used to be processed only after 30 days.

phew, yet antoher PR removing old DEVs credits...
https://github.com/SimpleMachines/SMF2.1/pull/611#

Yup ... another very poor attempt at listing names, is it really that hard to knowledge the folks that contributed code to a release? ... love the SM and SC decided comment  ::)

Did you guys notice the contributors file at the end of that with everyone in it?

Yep, and I think we should decide what to do with the credit page we too.

/me hides

Just create a list of contributors on a GA release date and use that in alpha order?  Just a link to https://github.com/elkarte/Elkarte/graphs/contributors ?

This is IMO fine and always up to date  :D

Question: if you're using Github, that only shows the GH contributors, not all the contributors in total, which means it doesn't include any contributions prior to Github.

Considering that you're calling us out for removing ex-devs credits, how does it work that that's essentially what you're proposing? Or do the SMF team contributions prior to ElkArte's formation on Github not count?

Seems a bit hypocritical to me. (And I'm one of those people who is trying to just list everyone, dev or not, that contributed to the project. I'm all for crediting contributions regardless of what badge (or not) they held at the time.)

That's right in general but I think SMF contributors have already been credited by holding SMF's copyright inside the files (Elk is based on SMF which was made by the SMF contributors) Either way, I'm fine with whatever we do..

No harm either in keeping them, I think the contrib file is a good thing to do. SMF's one should be a good starting point, we can trim and add as needed according to our own list of contributors.

Then, the credit page can be used to list the active contributors or something like that.

The ElkArte contributors are just that, those listed on GitHub, link it, we could also add the list at a release date if we wanted something static showing as well.

For the base code which we used to build on, we could add another section that makes special acknowledgement of that project and its members. To be safe we could just get the 2.1 list (whatever is decided) and use that.

Posting here so that I'll not disturb further the person that posted it.

The post is not intended to collect +1s, or to make people change their mind, or whatever.
It's just something I feel I have to voice, at least to fix it in my mind.

I just want to say, that regardless of any disagreement, what I always tried to (and I'm still trying to) do with all the SMF forks is to maintain a certain level of collaboration (Arantor and Nao should probably be able to confirm, and the fact I was an SMF dev until a month ago should demonstrate it as well, but I suppose it could also be used to demonstrate I was trying to take advantage of my position to put ElkArte in a better position ^[1]).

I find the very idea that I should mind my own business quite offensive, for what I tried to do in the last year or so.

I also find it offensive because is quite the opposite of what usually "Open Source" means: Open Source means collaboration, not fighting between projects because "I don't want to touch your code because it's yours". Are we so childish?
There is code, good code? Fine, I'm going to use it as long as the license allows me to. You may think it is hypocrite, well, to me it's not. It's just another way to show respect for your work: admins use the software, I use the piece of code I think it's worth being used.
What's wrong with that?
Are you scared by the fact that Elk code may poison SMF code?
Is the code we write infected like some kind of artifact^[2]?

Finally, I find it stupid (sorry if you are going to take it as a personal attack, but that's what I think) because "mind my own business" means for example that if someone reports a security flaw in Elk that is applicable to SMF as well, I should "mind my own business", fix it and publish the fix, potentially exposing all the live SMF installs to a 0-day attack. Is that what you would like to see? I guess not... I hope not. And sorry, but I wouldn't be able to "mind my own business" in such a case.

Well, that's all.
Sorry for the noise. ;)

There was a discussion about this, because the first I knew about it was when I saw the commit note about 'not making mistakes'.

Let me explain. Suki made some mistakes, she's human. I make mistakes, I'm human too. She didn't appreciate you pointing her mistakes out to her, especially because to her way of thinking, picking on her for making mistakes while making mistakes yourself is hypocritical, especially when you've said that you're not interested in developing SMF. It's not my place to say whether any of that is right or wrong, that just seems to be her opinion on it.

Me personally, I don't care if mistakes were made, or by whom. I just care that the result software stands up, and thus the bugs get fixed. I'm grateful someone who isn't me is looking at commits and picking up on mistakes, but I know I'm not exactly great about taking criticism of my code - and Suki is even less so inclined. That's really what happened here, a legitimate comment was made about a legitimate software flaw, but from her perspective it's all wrong because she feels that she shouldn't make such mistakes (at least that's my perspective)

The bit that seems troublesome for us (and I know both Suki and I at least feel this way) is that commits are being reviewed not so much for SMF's benefit (though we do get a little benefit out of it), but it is perceived that the review is only happening to see if it's suitable for inclusion into Elk. Now, I know that's the stuff of Open Source but it doesn't exactly set our happy bells ringing to know that we write code and a rival project (because that's what Elk is), is taking the fruits of our hard work. It's why Nao is so adamant about us not reusing his code from Wedge, and I fully get where he's coming from. It's one of the few things I do agree with him about. (But of course, going the other way is absolutely fine. ::)) That's ultimately where I think Suki was coming from, even if her attitude was not so tactful.

Look at it on the other foot, let's say I looked over Elk and cherry picked the post-by-email, footnotes, some of the other code and put it into SMF. It is, after all, open source and thus fair game. But would you be appreciative of me doing such a thing? Would you be as forthright if I were to review your code and fix bugs in it because I was reviewing it for inclusion into SMF? I'm not planning on doing so, I'm merely asking the hypothetical question. My gut tells me you may not be so positive about us doing it, even if it is fair game, and I hope it would explain why there has been some reticence on our side for such things.

Most of all, though, I hate that politics and emotions run so high amongst very talented people who just want to make awesome things. And if I'm brutally honest, I wish both Wedge and Elk never existed. I wish we'd been able to reconcile everything and make SMF awesome instead of having three divergent efforts each trying to do so, with all the sniping that has gone on at each other.

I know there's been a huge amount of frustration on all sides because of injustices past. Some are perceived, some are completely valid, and no-one wants anything to fail (I hope), but perhaps a little more tact and diplomacy on all sides might ease the fact that there's cross-over between the projects still and that we do have things in common still.

oh yeah, funny overreaction ;)

Keep in mind: Github's most powerful feature is IMO code review.  That's what eman did here and that's what we do here at ElkArte within the regular workflow. Someone sends a pull request, someone else reviews the code and gives feeback and/or merges it. That is IMHO so cool, to have someone else to look over my code (and for sure mistakes) because it will reduce the amount of bugs. It's better for the product and also better for me, because I can learn from other's feedback. I don't understand why you (over at SM.org) merge your own pull requests, the whole idea behind git / github is suspended by your current workflow.

That's the idea behind open source. But please keep in mind: We do not just steal your code.
1) We keep the SMF copyright in our files and therefore give credits to SM.
2) the "stolen" code is cherry-picked and you (as an indivudual contributor) will get credits for that part of code, too. Just check the contributors list at github and you'll find your names get listed there.
3) We still give back to SMF: Eman is a local moderator for the italian child board and active supporter. Spuds helped SleePy fixing the regex for PHP 5.5 compability. I for one am still helping the guys and girls who like to convert to SMF. Just check the converters board and you'll get an idea about my new nickname.

We aren't just thiefs, we also give back ;)

I for one wouldn't have issues with you picking our commits from ElkArte. That's the nature of open source. The only thing which is IMO important: my code was made for ElkArte, so the copyright is "ElkArte forum contributors" ;) This should be added to the header of all the related SMF files you are adding code from us.

LOL, yes, maybe.. but too many bullheads (at least I'm one) in a team isn't good :D

As I said I didn't write the message to seek for agreement, justifications, explanations or disagreement. I wrote it to clarify my own thoughts to myself.
But I also realised some kind of answer was to be expected. ;)

That said, if you take a look at the git history and my comments at github (I'm not interested in demonstrate what I'm doing, so I'm not going to dig to find evidences), you will see I already ported during the time several things from ElkArte to SMF (and I'm not "picking on her", ask Oldiesmann, live627, Spuds, TE, Norv).
I didn't choose a license just to be able to say "I'm working on an open source project", but because I don't care what my code is used for or where it is used.
If I were concerned by SMF taking code from ElkArte, I would have been in the front line to change the license to MPL or something similar. Instead Elk has the same license as SMF (not because of me, but because as far as I know only Norv proposed to consider for the future a change in the license and as a public reference I don't mind the license, I like BSD because it's short and to the point and I find MPL boring because is long, full of legal mumbo-jumbo, but apart from that one or the other doesn't make any difference to me).

---

On the personal level: read my signature (here). I never thought I write perfect code. I don't like as much as anyone else to make mistakes, but I do them. Surprise: I'm more happy if someone finds my errors, rather then my (more or less silly) errors compromise the final product. And "the next time" I'll pay more attention to what I write and I'll try to write it right from the beginning.
To me, coding in a project is not a personal competition at who writes better code, it's a way to improve myself as a coder, and help other people improve their skills. I'm not paid for what I do, I'm not receiving an award if I write bugs-free code (well, actually I received one for the amount of bugs I wrote! :P You can find the topic in the dev chat board at sm.org), I don't get penalised if I write bugs.
What from time to time I'm better at is read other peoples' code (maybe just because I don't know php well enough and I don't skip through the lines just getting the general idea of what the code does, sort of what I do with English). And I try to use that skill to help, but apparently in some cases, ego is more important than what we are working on^[1].

ETA: and if you think I'm writing this because I'm in some kind of need for "your" code, feel free to dig in the team board the discussion about opening the "forks discussion" board, I clearly stated that forks are potential source of code (if the license is compatible), ideas and coders, a long time before Dialogo was even a remote possibility.

---

Now, personal level with Suki:  as far as I remember, before yesterday, I "attacked" her directly and with the intention to attack, only once (http://www.theadminzone.com/forums/showthread.php?p=716670#post716670) (and as you can see it can't even be considered an attack to begin with).
Any of my comments on code are all the same for everybody. I'm not doing any favouritism to anyone (search where you want, you'll find my comments along the line of s/something/something else/ or this != that, etc.).

I proposed her to lead SMF into 3.0 about a year and a half ago when it was clear Fustate was no more interested in doing so (you can find the topic in the dev chat board at sm.org IIRC), when not even Dialogo was born, do you think I'm so stupid as to propose that to someone that I didn't think it could have been able to do?
I always respected her coding skills (well I have some doubts about some of her choices, but that's part of the game of confronting on a nondeterministic field), what am I supposed to do? Bow to her and ask for permission to report or commit a bugfix any time I find a typo in code she write[2]?

---

And just a final consideration: I'm sorry if it sounds harsh, but to be honest, if you two feel bad about others reusing your code, you are in the wrong place at the current SMF (not saying that to hurt or anything, just a plain interpretation of the facts).

Oh well, as opening post of the morning is fairly long and not really to the point.
Who cares.

I think code review is a great thing. The problem, as mentioned, is that some of us are not so great about handling criticism of our code as well as we would like.


Because if we were to wait for such, nothing would ever get done. There are already commits that haven't been merged yet and have been sat around for weeks despite probably working just fine.


I didn't say you did. I said that there was a perception of the fruits of our hard work being used, and if I want to continue to contribute, I'll just have to deal with that.


That's cool and all, but it still feels a little bit like you want all the benefits of SMF without being properly associated with us out of politics, which to my way of thinking seems a little bit childish but that's not a can of worms I want to open.

I won't deny that I feel a bit bitter because of other events, like someone accusing me of stealing code (an array declaration FFS) so I am perhaps not the most unbiased I could be.


Either you're secretly margarett or you're Dexter Morgan ;)

That's what I meant about there still being crossover between the projects, though. There is crossover and there's still things going both ways - but the *perception*, more wrongly than rightly (especially in my case), is that it was primarily one way.


And this is a good thing. It's just not always seen that way.


I want to believe that's true, I'm just afraid it wouldn't be if it actually came to it. As indicated, recent bitterness over something that shouldn't have happened doesn't exactly help on this score.


Oh, I realise that - but on the other hand, it did seem to me to deserve an answer. It's a legitimate criticism, albeit with a little bit of snark in there too - on all sides.


I know you weren't picking on her, because I've seen the notes and conversations with others. I won't deny that I tread carefully when expressing concern with Suki's commits to her. She is very protective of her work. I won't go into why that might be, or what led to it, but what is clear is that she puts a lot of herself into her work and is not particularly diplomatic about receiving criticism; critique of her code is critique of her too, in her eyes. Anything that seems critical - even if completely accurate - may be taken the wrong way.

I just hope that when the day comes - and it will - when you find a bug I made, that I'm more gracious about accepting it than I have been in the past about criticisms.


Ah, yes, the Grudge award. ;) I think I earned the lion's share of those for Wedge, actually, because I tended towards fewer, bigger commits rather than several incremental iterations of the same thing.

In an ideal world, that's how it would be. But in an ideal world we wouldn't make bugs to start with either ;) I don't care who makes bugs, though, I just care that they get fixed.


That's the ideal. Sadly ego will get in the way because we are passionate about what we do and it shows in what we do.


It's certainly been an issue in SMF's history. I'm trying to put mine aside but my ego is a necessary component of my ability to create things, the belief in myself and the ability to believe in my instincts as a developer. I'm just trying to learn to keep it under control, please bear with me in this brave new world.


Nope. You're writing this to express your views in response to mine. We are coming at the situation from difference perspectives and different experiences and right now I admire the fact that you're sticking to your principles. From my perspective, I am feeling more selfish and protective towards SMF, but not entirely out of ego. (I'm also well aware that you're entirely permitted to use the code without any contribution back whatsoever.)

I take the view, rightly or wrongly, that SMF is fragile and needs love - that it needs people willing to fight for it, willing to put in the time and energy to make it what we all want it to be - and then someone can come along and skim off the top. That may not be in the spirit of open source, but it means that what's the point of trying to improve SMF when anything I can give it to make it unique and competitive suddenly stops being unique or competitive because it ends up in the competition shortly after? Conversely, what's the point in trying to improve ElkArte with unique features if I were to import them into SMF shortly after? This is the one significant problem with divergent effort - we both end up imitating each other instead of forging ahead under one banner. We all know SMF could move forward more effectively with all that extra talent there.

I won't deny, my views are coloured by recent issues elsewhere with incompatible licences and being on the wrong end of opinions about how I could use even my own code, though.

And let's face it, I'm not as pure of heart as I would like to be. Pure open source contribution is a beautiful thing. I am not so pure of heart yet that I feel comfortable with that. I feel the weight of injustices past and present, knowing full well that SMF wouldn't even have an open source licence in the first place if it hadn't been backed into a corner about doing so.

When I stepped up to support SMF, it was a conscious decision to try to improve SMF, not the rest of the ecosystem. I did not do so for Elk's benefit, nor for Wedge's benefit, nor for anyone else's benefit - and yet Elk and Wedge are going to be able to reap the rewards of my hard work. This is a failing on my part to fully deal with right now. And I'm well aware I'm projecting my personal failings beyond myself, which is inappropriate, but I can't change how I feel, even as much as I want everyone to work together better. I'm still trying to get my head around my work being more open than it's ever been before, including for projects that declared they didn't really want anything to do with the one I chose to contribute to.

I guess it's because of the personal and rival nature of it all; if I were to contribute to jQuery, for example, I wouldn't have any issues with people using my work, because I'd never interact with the users downstream much. I might feel aggrieved if Prototype or Mootools used some of my work, perhaps, because it's a rival project using my work and I'm still too protective of it. This is, of course, personal and not related to SMF's team. And it's something that for the good of SMF, I will just have to suck up and deal with - and I will in time. I'm just getting used to this, because I've never done this before, not like this.

I also know that I'm adding things to SMF at the moment that are significant in SMF's history, and I don't like the fact that they are things I suspect Elk will adopt if it has not already adopted some of the aspects of them (haven't looked), but I haven't even told the team what they are yet, I'm just going to do them and see what happens ;)

I will also add, I think I can understand how the SMF team felt in 2010 after they learned about Wedge emerging as a fork and how unpleasant, in hindsight, Nao and I actually were - me especially, I think. I'm trying to learn from that and not to repeat it. I just may have gone a little far the other way right now.


Ah yes, that particular matter. This is one of the many things I've never been entirely happy about, but fortunately stay away from much of the time. It's also a matter I've never drunk the kool-aid of that 'donation => helpdesk = gift for donating', because it's not in my opinion, it's still effectively a paid-for support option, in my personal opinion. The powers that be disagree, and that's fine. I just choose to avoid it as a result.

I don't, actually, disagree with the comment made - it wasn't even entirely an insult. It was a robust criticism of what was said and how it was said, not of the person saying it.


Not at all. I think we both agree on her having the technical chops to pull it off. But diplomacy is a skill yet to be fully embraced.


Do what you feel is right, of course. I'm not for one moment suggesting that you shouldn't report a bug if you see one. The most I'd suggest is being more tactful about it. I find phrasing it as a question tends to work better than stating it's wrong. Asking if it's supposed to be the way it is rather than asserting it is other than it should be.

On the other hand, you could just do as you do now and let her handle it badly if she wants to. She actually seemed quite upbeat about it after the fact in IRC. Either she'll learn to be more diplomatic and more gracious about accepting that her code can be wrong even without her being wrong, or she won't. If she leaves in the end, it'll be a blow to us but we'll muster onwards.

You're a smart bloke. I figure you'll do what you feel is right. You also know where my inbox is if you want to rant about things or whatever.


It's a valid criticism. I'm still getting used to this idea that my code can and will be reused even by my rivals. I will get to the point where I am comfortable with it - but you must understand that it's only been about 6 weeks since I started contributing truly openly. At no point before this did I ever create anything that even potentially might get forked - even SimpleDesk with its BSD licence never got forked, let alone by a rival, so this is a new experience for me. I suppose I should be more appreciative that my ideas are being reviewed for inclusion but my ego is still a bit too raw for this.


I care, because this is something that does affect both our works. And I don't like leaving things on a sour note if I can help it.

Y'know, a really dumb and naive person might think that starting a brand new project on a brand new site would be a good way of leaving SMF bunfights behind. Tis a radical notion, but methinks it might be possible. :P

It might, if the principle contributors weren't still - by their own admission - involved with the original project. That, incidentally, is part of the perceived problem.

EDIT: I'd be quite happy to leave the bunfights behind, though I'd note this last discussion came out of a bunfight that didn't need to happen because of egos, certainly didn't need to happen here, because it should have been kept at sm.org since it was about critique of SMF not of Elk...

Arantor. You put yourself in that situation. Don't you ever blame anyone else for something you did entirely by yourself. (Leave a closed license project, decide to contribute to an open project, and then complain that people can take your signed off code and you can't take a single line of code that wasn't signed off.)
You do that, it's on you. Stop insulting my intelligence. Not only did we never take new features straight from smf 2.1 (and I have absolutely no plans to use any of your new features for it). But. Everyone that is not Wedge is in the same situation as you are regarding taking code from Wedge. You're a SMF developer with a clear intent to implement Wedge features and you have access to my codebase. I can't afford not to be protective of it. It's a time costing work (checking your SMF commits and posts) that you chose to impose to me. You're incredible!

You heard it here first, folks, Wedge ain't going under an open source licence any time soon. Because the minute it does, it opens itself up to the exact same issue.

You chose this license with me. You were quite happy with it. Then you chose to leave. And you said Wedge (half your work, shall I remind you) sucked. You really should get your act together. Either say things honestly or don't. Trolling isn't your finest feature.

PS. We always said Wedge would remain under that license until we both lost interest in it. Selective memory much?

A suggestion would be to make your repo(s) Private, then no one but whom you decide/invite would be able to see what you are doing.

Nothing in BSD requires you to have an open changelog, commits, etc.  Just keep it hush and the only time the public or competition would get to view the code is when you tag it (for a release or a pre release).  GitHub with that open repo was a test in many ways, if its not suiting the needs of the organization, or the complications are greater than any benefit, then there are several options for you to pursue other than a bunfight.

A private git repo or even back to SVN, would allow you to keep others away, you could still leverage code / features from other projects, it would prevent any early forking and/or rebasing, ie only SMF 2.06 could be forked until such time as you tag or provide an Alpha release.  Heck you could even special license any early releases and not allow forks until a gold "bsd" release.  And of course nothing says you have to remain open source for 2.1, although that may have some "complications" at this point so maybe 2.2 you close.

Anyway just some suggestions.

I'm not saying this topic should be discussed or not discussed, I'm just saying this topic reminds me of hanging out at SMF.  It's creating a negative atmosphere.....period. It is what it is.

Is it really necessary to pick apart someone's comments in a rebuttal? Yes, if your in a political election. :P ^[1]


Otherwise, focus on the path ahead, not the trail that was left behind. Just my 2 cents.

Thanks for your comments and I tend to agree with you on that, there was some discussion of de-stickying this, maybe even locking it at this point since it served its purpose long ago.

Sounds like a plan.

It all depends if the baggage slows you down. Sometimes you have to let it go and it means addressing it, rather than leaving it home.

I know I still have unresolved issues with people at SMF and even Elk for instance. Generally harmless stuff but... If they have to come up, I won't pull them back in. Luckily I'm usually too busy to bother. :P

Some people never get closure, no matter what you say or how much you say to them. It just never ends.

People get good at what they practice. If a person practices hanging on, they get good at hanging on. If they practice moving forward, then they get good at moving forward as well. Same goes with everything they do...