I have a question.  How compatible will mods for SMF be with your fork?  I was able to write one for SMF1 easy enough 2 years ago and then thought nobody would want it because everyone was going to 2 beta and I gave up on trying to figure 2 beta out.

Recently I've tried again and thanks to Arantor I'm further ahead than I was 2 years ago when I gave up.  Not done by a long ways but at least the db stuff is working.

So will I need to make a third version for Forked SMF?

The simple answer is yes, you will need to modify your mod - substantially, in all likelihood.

Firstly, $smcFunc is no more, it doesn't exist at all in the fork. Secondly, and more importantly, the whole system is going to be shaped more and more over time to avoid this tedious, fragile process of code modifying. For the vast majority of things, it's simply unnecessary - even in 2.0 RC4 it's less necessary with the integration hooks that are present, but the whole system needs to be massively expanded for it to be really useful.

Success also means more responsibilities... It's a double-edged sword

Havent you invited some former old Developers from SMF like Aaron van Geffen who did so many good things, in translations, or do you just wanna keep them outside your door?

Yes and no. Yes because Aaron is interested in the project and he's started to participate, and no because we're still not taking proper developers. Probably not going to happen before v1.0 is out, really.

Basically the team is just us, Arantor and Nao. We are both leaders and developers.
We both think that a project can only thrive as long as it is led by people who actually work on it.

Apart from us, our private forum has a few dozen members, either Pete's or my online friends. Among them, there are a few 'consultants' (i.e. people who can access our codebase and demos and give advice about them... Errr... They're not doing that much because it's hard to follow us but that's the idea ), and in the future we will also have 'guest developers', i.e. people who don't have commit access but who provide source code anyway, for a specific feature or so. We don't have any preconceived ideas about whom should be able to join forces with us, really. We're obviously a bit wary of seeing SMF teamies join us[1], but we have plenty of ex-teamies who've found renewed excitement with our project.

Aaron is very welcome to become a guest developer, of course. He only joined recently our forum, and right now he's getting acquainted (and overwhelmed) with our feature set. (Poor thing. Just for the record, there are close to 9k posts on the forum already, including 6k+ by Pete and I. And you have to read them all. There's a quiz at the end.)

But there is still time to decide everything, since we can't even release a beta version before SMF2 Final is out, and now that they're going to release a RC5 instead... :

As far as i am concerned i will go with the fork, i love the mediasoftware you have made as we use it successfully on our Forum.

Well, if you're an AeMe addict, I guess you're better off with our fork in the future, since I've completely stopped developing it for SMF. (The fork is so much easier to work with, it would be a nightmare for me to go back to SMF.)

1.	Let's just say that our license even 'accomodates' for a few of them being potential nuisances... :

Sure, we're hiring right now I think

Define 'email obfuscation'

That's the default in SMF 2.0 anyway. Users have to opt-in to their email address being seen