(Co-written with Pete, aka Arantor.)

Juxtaposition

For 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.

Sadness

The 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.

Separation

We 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!

Divorce

On 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.

Determination

Yes, 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.

Suggestion

Before, 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.

Preparation

We 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.

Vilification

I, 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.

Retaliation

Now, 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.

Protection

Because 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.

Vision

Remember 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.

Anticipation

We'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.

It's still time to rename your threads.
Actually I thought of it only yesterday. Then I Googled "fork you" and found that it'd been used in blogs as recently as those covering the LibreOffice fork. So much for originality, not that it's surprising. But still, I wanted to use it, because it relays conveys my feelings for a team that has consistently tried to find every little chance to screw us.

I'll take the liberty to reply here to the second question by quoting Arantor:

We have intentionally decided to break compatibility with mods and themes, because mods will be required to be rewritten (and with how SMF is structured, it's kind of hard to do anything really interesting without breaking compatibility)

Themes too will need some substantial work to be made to work, not least because of the structural changes that have been, and will be, made.

Sure we'll remove bugs from RC4, we just won't be giving the fixes back to SMF. Some of the bugs will disappear because the underlying system will be replaced; the current WYSIWYG editor will almost certainly just be replaced with something that isn't buggy.

You can be close-minded with open source, just as you can be open minded with closed source, and really whatever we come up with won't be truly closed source, just not entirely 'open' by the FSF methodology.

It was open minded - YaBB was forked into YaBBSE under the GPL, then you had a couple of very aggressive forks (like copying it, search/replace in the files and republishing). So with SMF they decided they'd not allow forks because they didn't want a repeat.

The whole GPL thing is pretty complex but I'll try and explain. Joomla is pretty militant about their interpretation of the GPL - you can be GPL and easy-going (granting licence exceptions in the name of good will) and you can be GPL and militant (like Joomla, WordPress and others)

The problem arises when you get into the realms of bridges. Specifically, when you have some code that runs in the same memory space and execution as a GPL app (like you include the file and run it), that's considered a derivative work and the resultant production should/must be GPL licensed.

Where you have a bridge that runs code inside both Joomla and SMF, the bridge must be GPL to be compatible with Joomla (since they're militant and don't even like LGPL stuff) if you want to distribute it. And since another part of the code would have to run in SMF too, you have to find a way of running it inside SMF without forcing it to be GPL code since the rule about redistribution is violated by SMF's licence.

Let me clarify something just here - it's not about doing it. It's about distributing it for others - I can sit and bridge the two, that's cool. But I can't redistribute the code because the resultant work isn't a GPL licensed work.

In theory, though no-one's ever done this as far as I know, you could dual-licence the work under a GPL/BSD licence and get round it that way, but Joomla in particular is pretty hard line about it.

There is the route that JFusion takes, which doesn't use any Joomla code, simply the database itself - this is defined under the terms of the GPL as a 'common interface' which means it does not have to comply with the terms in the same way since it's not code being run in the same memory space.


Licensing is a royal pain the arse.

Where you have a bridge that runs code inside both Joomla and SMF, the bridge must be GPL to be compatible with Joomla (since they're militant and don't even like LGPL stuff) if you want to distribute it.

Well, that's a problem... Whether they're militants or not, LGPL *is* GPL-compatible and they can't do anything about it.

In theory, though no-one's ever done this as far as I know, you could dual-licence the work under a GPL/BSD licence and get round it that way, but Joomla in particular is pretty hard line about it.

Ah yes, dual licensing... I never really caught the concept but I saw it done multiple times, such as for TinyMCE etc...
If Wordpress has no problem using TinyMCE, which can be tied to non-GPL code, then dual licensing could be the thing to do.

There is the route that JFusion takes, which doesn't use any Joomla code, simply the database itself

Does a bridge need anything else than the database structure anyway...?

Boy I am asleep again only noticed this now  Is there any mention of this fork on the SMF site at all?