Glad to hear you guys are still fighting the good fight. I have high anticipation to see what you all come up with. I am also interested to see the performance improvements that are found by getting rid of all the legacy support (php 4, old mysql versions etc)
If there are any performance improvements in that respect, they're probably negligible. I didn't make any benchmarks myself. First, because our fork (whaaaaa I started typing its name, I have to be more careful....) isn't flat out compatible with SMF (it will require importing the original data, which has the added benefit of allowing users to compare apples to apples by running both identical sites in two different folders and then deciding which best suits their needs), and secondly because we're doing most of our tests on our local machines, meaning it IS ultra-fast anyway.
Our concern is not performance, it's usability and features first. I can be quite obsessive about performance so if there's an area that's definitely slower, I won't have rest until it's fixed. There are places here and there where SMF isn't efficient and when we find them, we make sure to rewrite them, but remember that in a PHP script, at runtime, 95% of the time is spent on 5% of the code. This is where performance is important. There is no point in optimizing an obscure function in the admin area that no one ever uses. Basically, in SMF, the deal-maker or deal-breaker is parse_bbc(). We haven't tackled this one yet (except for moving all of the BBCode to the database, allowing for mods to add their stuff to the database without worrying about editing files. Pete focuses a LOT on trying to keep files clean from mod edits, which is fantastic.)
What else? I don't know, we're only at the beginning really... We've been on it for over 4 months now, but it's far from ready for release in my opinion. Of courset that's partly due to the wait for SMF2 to be released -- in the early days, we were planning to release the fork in time for SMF2's release, but then it became obvious that the SMF developer team was too slow. When I fixed about 30 bugs in a month back in June (my infamous stint as a "consulting developer" over there), they only fixed 7 or 8 bugs in the last 4 months, and apparently they intend to release a bug-free SMF, so I'm starting to even wonder if we'll see SMF2 Gold before next spring... For that reason, we pretty much threw away our plans to have a "much improved SMF2" and instead went for the "perfect forum" vision.
And believe me, it's going to rock.
I am curious about some topics that you addressed but I am fuzzy on... are your plans to integrate aeva 100% into the code or just leave it as an addon/mod/plugin?
100% integration, as mentioned elsewhere.
It's way harder than it sounds, BTW. Because of our changes to the codebase, a lot of AeMe's code is outdated. Going HTML5 is not exactly funny when you have dozens of tables in the template. (Yes I know, I could go tableless, but I'm focusing on the fork first. AeMe's templates will come later.)
Regarding AeMe's development, as I said before, it's on hold these days, because of the massive amount of work on the fork. When the fork is finally released, then I'll be able to start working on the gallery again. Sometimes I miss that. I really enjoyed adding features to it... And as I (again) said before, the fork will have AeMe2 by default. A few features may remain available only for 'charter members' or an equivalent group, but that'll be way cheaper than a SMF charter membership. (I haven't discussed this with Pete, but I suspect he will agree that we want to have several levels of charter memberships, one that gives priority support, and one that doesn't.)
You mentioned a default portal and I have seen several threads about portamx as a candidate.. would this be a addon or be included by default?
As Pete said, PortaMx -- no thank you. I already told the story. I offered feline a spot in our private forum to give her a chance to share her ideas about performance improvements in SMF (something she enjoys doing but nobody in the SMF team even listens to her.) She said she'd only share her ideas if we gave her "half of the shares in our company". Since she calls herself a "corporation", she must have some delusions about everything having to be backed up by big names. No, that's no our thing. We're not doing this for money, we're doing this because we're two excellent coders and we were pushed away from the SMF team for also being vocal internally about the team's inability to do anything correctly.
So what we're doing here is *work on SMF* the same way we would have, if they had a competent team that recognized the interest in having Arantor and Nao join their developer ranks. Right now, they have Norv (who's busy on other things), and Antechinus (who's... busy on other things). That's all. Their only remaining developer, Sinan, no longer works on the project because he's been criticized for adding bugs to the codebase. I told him, SMF is a huge project, you're bound to add bugs to it, but that's what other team members and beta testers are for: they test your code, find bugs, report them, and you fix them. That's no big deal. Better doing two steps forward and one step back, than not moving at all.
Anyway... That's our point of view. And that's how I made AeMe. I coded, I published, I got bug reports, I fixed them. The latest versions available are pretty much bug-free AND feature-packed. If I had been so scared of committing bugs, then it would have only been bug-free. With the feature set of an SMF Gallery Lite (ahah.)
or would these things be like the calendar in smf.. included by default but not activated?
I'd personally want to see our portal activated by default. I mean, if we're going to write it from scratch, we might as well show it
The homepage will be a given anyway. I can't believe that in 2011, SMF is able to launch a forum system that, by default, offers such a boring homepage. It doesn't make one want to visit a forum.
is it possible to fork an existing portal (I dont know about their licenses so might be a stupid question) like tiny portal/simple portal since portamx's developers are being unreasonable?
I suspect Pete was talking about Dream Portal, because it's BSD. Problem is, we went upfront about this to them, and they said "no, you can't fork us". Then we kindly reminded them that we didn't need their authorization to fork it. They still gave us the finger. We have their main developer on our friend team so I don't know if it's related in any way. But it's certainly an area I'd still like to explore when we come to the day we start implementing a portal. I'm not a big fan of existing portals, but Dream Portal certainly is an interesting choice, and as I said, it can be forked. I can live with being 'enemies' with the software we've forked. After all, we're doing it already with SMF....
Finally, just to play devils advocate.. by not leaving the BSD license and going to a closed license arent you putting the project in danger of eventually falling in the same traps and annoyances that SMF has?
We never said we wouldn't go BSD *after* a while.
Originally we were going to keep the BSD license but then I talked with Pete about the drawbacks of that choice.
First, you must keep in mind that we're doing a hostile fork. It's not something we decided to do, eh. SMF basically kicked me out of the team in July, perm-banned me in August, then after we announced the fork, they quickly removed my beta tester rights -- even though I was their most active tester and still suggested bug fixes after being banned! -- and my credits as well. We're not a hostile fork, precisely THEY're hostile to our fork.
So, because of the hostility, what do you think would happen when we go gold? SMF taking our codebase and renaming it SMF 3.0. That's what would/could happen. They would have to credit us in the files, of course, but they wouldn't care because they'd have screwed us. And even if SMF didn't do that, I'm sure vbLamer45 or another jerk would do it just the same.
Basically we're protecting ourselves to give a chance to our software to become well known.
Then, if the fork becomes somehow popular and no one can fool us with an early fork that attempts to cash in on our work, then we'll consider going open source. It's my personal plan, I think it's Pete's plan, we like openness but we'd just like everyone to remember that we're working on this fulltime, on OUR personal funds, and that there's no reason for this to change in the near future.
