[EDIT] someone pointed me (in a completely unrelated discussion - i don't even know if the other person ever heard of phpbb and even if they did, i doubt very much they care one single bit about it) to this very interesting article.
you want to read it.
so i attach it to the head of this post i wrote earlier.
http://www.joelonsoftware.com/articles/ ... 00069.html
[/EDIT]
rewrites do not have to be "ground up".
e.g., if we want to create a data layer between the application and dbal, it can be done in a completely disjoint manner to upgrading the template infrastructure, which can be done completely independent of moving to a hooks/plugins system.
the problem with creating a new system "from the ground up" is exactly that: phpbb is the most successful OS forum system on the market today.
people stay with it not just out of loyalty, but also because of the the technical reasons that make it attractive, as well as the vast array of MODs, translations and styles available.
updating, say, the template system might make a lot of the styles obsolete, but keep the MODs and translations still valid. one hopes that the style designers will bite the bullet and update their styles.
removing the MODing modus operandi and moving to plugins/hooks system will render the MODs obsolete, but will carry forward the styles and translations, and one hopes that most of the MOD creators will bite the bullet and translate their MODs to plugins (or create new ones with similar functionality.
doing it all at once: rendering existing MODs, styles *and* translations all obsolete at one go for a system that is almost completely new and hence not-proven with a whole array of unknown potential issue, one might ask: "why should i? if it's all new, i might just as well go with something completely new *to me*, but which have existed for a while and i feel pretty confidence is working and stable".
in software development, i *always* prefer steady evolution over "intelligent design".
when we moved from 2 to 3 the situation was different, because, even though phpbb2 was vastly successful in the marketplace, the codebase was crap.
phpbb3 codebase might not be the epitome of high quality software engineering, but it's not a piece of crap either. i do not think that completely scrapping it and starting "from the ground up" would be a good decision.
so my vote goes to "revamp one subsystem at a time". even huge changes, such as moving to a framework-based architecture should be as little mixed with *other* changes as possible, release, stabilize, and then start dealing with the *next* subsystem you want revamp. repeat.
so if you want to move to a framework, do not touch dbal (unless the framework actually *replaces* the dbal layer). do not touch templating (again, unless the framework replaces the template). change the style as little as necessary. do not add features.
release.
then focus on the next target (say, a plugin system)
release.
next, do the next target (say, switch to using a data layer)
release.
next, say, do a feature release, integrating or replicating the most sought-after MODs.
release.
we can still do minor features in an infrastructure release, and minor infrastructure improvements in a feature release, but the principle is this:
avoid "ground up" type of changes. anyone who remember the painful experience of 2002-2007fighting to get way-too-overlosed system out the door while the existing user-base constantly gets more frustrated because of what was perceived as stagnation, knows what i'm talking about.
change one thing (or at most, two) at a time.
release early.
release often.
this has little to do with version numbers, of course, it is more about software engineering/managing OS projects philosophy.
peace.
