What you are calling 'most needed features' are pretty much all at the very bottom of my todo list. Can't speak for Nao though.

A portal, yes, probably.

Pretty URLs is already implemented. Meta tags, yes I'll do those but not because I want to. I'm implementing those to basically defuse the "it's not good for SEO" horde BEFORE it starts. Meta tags do surprisingly little for SEO, doubly so for a forum.

If Google doesn't index your forum it's because of mods you have. It indexes mine just fine... probably because I'm not trying to shove SEO crap down its throat.

3. There's plenty of internal linking in SMF already and inherited in the fork. Again if you have issues with it it's probably either because the server is slow or it's broken by one or other of the things you've done for SEO.

4. Basic template yes. Basic template editor... it ain't on my todo list, because it actually creates far far more problems than it solves, because it invariably gets too powerful for basic users and too simple for advanced users leaving only a very tiny percentage of people it actually benefits.


Let me say this again, and remember, this is important.

We aren't doing it for you. I personally do not give two hoots if anyone uses it or not. I at least am doing it for me, for my use and making sure that I build it to cope with whatever others want to throw at it. So you can jump up and down and say you'll make the switch if we add a bunch of features that I at least am not overly interested in and as stated are implementing mostly to prevent people whining at us (less people whining about things that don't need fixing = less support hassles = more time we can actually code), but that sounds like an ultimatum to me, and I don't do so good with those.

Here's the deal: we're going to add features, that we want to use, that hopefully others will want to use too, and we release it. You install it side by side, try it out and if you like it enough, you keep it. Otherwise you ditch it and stick with your existing stuff.

That works great with me because you get the freedom to try without any obligation on your part, we get to release it without any obligation on our part, everyone's a winner. Except the people who tell us what we should or should not do, who will likely end up very unsatisfied because we're not building their dream platform, but building OUR dream platform that isn't quite up to their perfect standards.

We're not holding a gun to your head, we're not demanding you use it, nor are we begging for you to use it. When it's ready, it gets out there, and it's YOUR choice whether you try it, not ours, and throwing me a line of 'if you add x, I'll make the jump' doesn't inspire me at all. It actually makes me less interested because I have no time to cater to people who want it exactly their way.

As it happens, the project I originally purchased them for fell through a couple of weeks later so I didn't need them but kept it in case something else came along.

You see, there's the problem. He could have done that. He could have just spoken to me and tried to resolve it like a normal, decent person. But no. He terminated the licence.

Since 2.04 was published before RC4, and RC4 did a lot of banal things, it's probable that work is needed, but after the way the team carry on, I don't know what Nao's plans are with respect to AeMe updated for RC4, I know nothing I've written is being updated.

Not that I'm aware of, and if it were mentioned, I doubt the thread would be allowed to remain there that long.

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.

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.

That's because it's only good for SMF 1 forums... won't work on SMF 2.0 where the structure has changed.