(Co-written with Pete, aka Arantor.)
JuxtapositionFor some time I've been worried about the course SMF is taking. New issues arose between the SMF team and us this week that just cemented how we felt, so we thought we'd actually announce something that's been going on.
We both did our best to maintain a working relationship with the SMF team, and we both feel that we're the ones always expected to compromise, with unpleasant consequences as you've already heard.
SadnessThe SMF team has been actively pushing away some of the most important contributors to SMF, such as us, Runic or the team that went on joining Yourasoft in January, simply because we were more vocal than others about the state of SMF and its team.
Some of us got bored waiting for changes, and simply left SMF to die by itself. Others wanted to see the SMF software live on and be able to tackle the new challenges that await it. Unfortunately, with the SMF team insisting on keeping SMF compatible with 5-year-old servers and software setups, and the "feature-frozen" state that SMF has been for the last 2 years, it was impossible to even try doing something about it.
So, in mid-August, Pete and I started discussing the possibility of branching off from SMF 2.0.
SeparationWe figured, we can work together, away from the SMF team, away from the influences of as many wrongs as possible that SMF fell into.
To us, the main problem was with the SMF team, and getting rid of that element in the equation would pave the way forward. The idea was really simple: make a fork on our side, where the project managers are also the only developers, and never let anyone get in the way without being sure that they share our vision of the ideal software. Then, make sure to collaborate with the SMF team to share our bug fixes and feature implementations, so that they can also freely be added to the SMF codebase.
And without boundaries, everyone's a winner; just think of the possibilities!
DivorceOn August 25, we got started on development, and we contacted the team to negotiate a licence to fork SMF. With 2.0 final, it's moving to a BSD licence, forking becomes inevitable anyway, so we figured offering them a way to mostly get rid of us much sooner wouldn't be a bad idea.
It was intended in every way to be a friendly fork; as bugs got fixed, the fixes would go back to SMF (both of us fixed things for RC4, for example)
The request was ultimately denied, both by the NPO and the LLC. It's understandable, knowing as we do the reasons for the no-forking clause in the licence originally, but knowing the eventuality of licence change - work commenced anyway.
DeterminationYes, that's right:
we are actively working on a fork of SMF - the licence doesn't prevent us doing that, all it prevents is distributing it and removing the copyright. (And if you think that's not the case, please read the SMF licence again.)
If it did prevent private forks, you'd never be able to have private mods and customised sites. As for us, we're just waiting for 2.0 final and the result licence change to be able to go properly public about it.
SuggestionBefore, I mentioned a new theme and new features - this was our way of saying that we're working on our fork. These are, or will be, in the fork itself, along with plenty more besides.
Lots has been done already - for instance, SMF is filled with compatibility code, changing a feature tends to break something else.
We must have pruned close to 15% of useless code by dropping support for many technologies that are either too old, or irrelevant in the SMF landscape: PostgreSQL, SQLite, PHP 4, MySQL 3.x, non UTF-8 character sets and many others. Things like the help manual were removed, because we strongly believe that if someone needs to read a manual to do something, then something's wrong and we should rethink how we do it.
PreparationWe did originally plan and agree to keep this quiet, and we're not revealing where the discussion is taking place for the fork, for its features and development, but it isn't here (but on a dedicated, private site.)
It is finally time to reveal because the team has shown hostility to both of us, and even more so in the last few days, and we feel it is totally out of line. You already know about Pete's issues with vbgamer45, and the SMF steering committee taking a stand to protect him, even though he's broken pretty much all of the SMF team rules -- several times.
Hell, he's been accused of trying to kill SMF. He might as well actually try living up to that claim, but for the right reasons.
VilificationI, on my side, had requested for the ?action=credits link to be visible in SMF, as it is currently not even linked at all in SMF. In order to make a point, I moved the SMF credits at noisen.com from the footer to the credits page, and proceeded to link to the credits page from the footer. This was denounced by the SMF team as a licence violation, and as retaliation I was stripped of my credits, SMF Friend status, beta tester membership and access to the bug tracker and SVN... before anyone said anything to me.
RetaliationNow, considering that such a behaviour would be perfectly accepted in a few weeks (because of the upcoming license change), and that the copyright was still there (albeit on a different page, but still just as accessible from the footer), and finally considering my role in helping SMF's popularity in the last few years with Aeva, I could hardly be put on the same line as a random user installing SMF and removing the copyright to replace it with their own.
What would have happened to Jeff Lewis, one of SMF's original creators, had he installed SMF on his website and removed the copyright? Would he have been banned for that? Oh wait... He'd been banned from the SMF website once before for less than that: questioning the team leadership, along with multiple others (see events in January 2010.)
Setting this aside, I didn't mind (much) about the retaliation. I was much more annoyed by the fact that (1) nothing was done to ensure that the credits link would be indeed made active in a vanilla SMF install, (2) the SMF team actually chose to get rid of one of their most active community members ever (without even a warning), instead of discussing the issue with him and listening to his requests (i.e. to make the copyright more meaningful.)
Not only that, but the SMF project manager, who is aware of our fork and accepted its very idea (without which we might not have started it, because we really wanted to be friendly to SMF), insisted personally on removing beta and SVN access.
What that means is, we can't see some of the new bugs or suggest fixes, nor report anything on the bug tracker, be it bug fixes or feature improvements. The SMF team has, effectively, shunned us from any potential influence over the future of SMF.
In short: SMF has turned our friendly fork into a hostile one, just like that.
ProtectionBecause of that, our fork will not, initially, receive the same BSD licence that SMF will have at that point; the original SMF code will still be BSD licensed, but the package overall will have a custom licence, because we do not want the team making off with some of the code. If they don't want to share their work, we won't share ours, as simple as that.
It won't be ready for public launch until after 2.0 is out, because there is so much we want to do with it that we haven't done yet, but it'll be out probably before 2.1 is ready, and with more features to boot (lots, lots more features, including ones the team would never consider putting in the core.)
We originally wanted to release a first version by the time 2.0 Gold is out, but the more we worked on the software, the more we realized we could do to improve on it. So, we simply decided not to give ourselves a time limit. Those of you who are used to using SMF RC's won't be far away from home. Even better, since most complex mods will have to be partly (or completely) rewritten for the fork, we will encourage development techniques that ensure they don't touch the main codebase, which in turn will allow anyone to update betas without losing anything.
VisionRemember this is Nao + Arantor, or Arantor + Nao (whichever sounds better
) at the helm - between us we have literally thousands of hours, and tens of thousands of lines of SMF related code under each of our belts.
Our fork, while it has only been worked on for a bit over 10 weeks, already has some impressive statistics. 240 commits (some of which add large new features), thousands of new lines of code, huge changes in both the frontend and backend, all within a global patch that would total over 2 megabytes if applied to SMF.
AnticipationWe're both committing ourselves fulltime to our project, and not expecting anything in return, if only for people's respect for what we're trying to achieve. That the SMF team themselves is no longer willing to respect us, only reaffirms the feeling that we took the right decision in forking.
When the time comes to release our first version, you will be able to install it next to your SMF forum, and compare the two different philosophies. Switching to it will be your own choice. It's been a long time since you've had a choice to make, rather than have a choice imposed upon you, hasn't it? Let's hope it will be the beginning of a beautiful friendship.
Minification (for those who want the tl:dr version)
We feel screwed by SMF, we got tired of taking it, so we're branching off from 2.0 now in a private repository and will go public once the licence to SMF changes.
Common sense - What does this mean for Aeva Media users?
Obviously, you all noticed that I slowed down work on AeMe in the last couple of months. This has probably been the hardest thing to do for me -- push the project aside to work on the fork. I'm still working on AeMe and playing with the layout and new features, as you may have noticed. The auto-embedding component of Aeva will be a core feature in our fork. I'm also considering integrating the gallery as well, although we haven't made a clear decision yet.
Et il y en avait vraiment deux ou trois d'excellents dans le lot. Alors je sais pas... J'ai pris l'habitude d'écouter cette "fausse BO", j'espère juste que Daft saura relever le défi, parce que l'air de rien, y'a beaucoup de gens pour qui Tron fut une fucking revelation dans leur enfance... Moi, c'est Tron et WarGames qui m'ont lancé dans mon métier. (Surtout WarGames, quand même. Mais bon, ça c'est moins fun à remaker aujourd'hui. Ils ont fait une suite y'a pas longtemps d'ailleurs, paraît qu'elle est pourrie.)
