Malthe Borch has a provocative take on what he calls a revolutionary approach to future Plone core development. Basically, create a parallel branch of Plone that uses the same recently componentized packages in the Plone core, but is otherwise free of any backwards compatibility requirements.
This idea is always attractive to developers. Why deal with all the cruft accumulated in years of evolution when you can start with an almost blank slate? A complete rewrite can lead to a cleaner, more modern implementation and in a shorter time too!
The problem is that, first, this is not entirely true. Second, you may lose many users while you do the grand rewrite and even after you are done (assuming some fairly flexible definition of done, because getting that rewrite to the dreamed-of perfect state envisioned at the beginning is really easier said than done).
We've had a very close complete rewrite experience in the Zope community in recent years. Zope 3 aimed to be the replacement for Zope 2, and some very good developers underwent the task of taking all the lessons learned from years of Zope development and distilling those into a new version of Zope that also took into account modern development paradigms.
The result? A new, great, powerful, successful web development library...which almost nobody knows or cares about outside the Zope community. Those who know that it exists are often very confused about its relationship to the old Zope ("please sir, could you tell me how to install Plone on my new Zope 3 instance?"). Heck, I have been following this story for years and still don't know whether to call Zope 3 a library or a framework.
Keeping the Zope name also backfired in unexpected ways, as the project inherited the perception of unwieldy and unpythonic (whatever that means) that it's namesake had acquired in the Python community by this time, thus limiting the number of new adopters.
I think the Zope 3 story shows us that it takes more than a name to maintain continuity between two otherwise disconnected pieces of software. You need an active and ongoing effort to make this connection apparent to outsiders or you will get a lot of confusion. Like Paul Everitt said in the comments to Malthe's post, until the Five project came along, there was no apparent bridge between the projects, thus the Zope 3 name turned out to be misleading.
The truth is, there are many uncertainties in a developers work to even think about working with a framework with an identity crisis. That's what you get with complete rewrites of frameworks with large user bases, because inevitably, a large portion of those users will stick with the old code. A good level of backward compatibility is necessary to maintain the user base. You just can't tell a user that all or most of his accumulated knowledge is no longer useful, even if it's for the better (in many cases, this means better for the developer, not the user).
To be succesful, a revolution needs to get the support of the masses. Thus, its ideals need at least to be based on the people's aspirations and needs. That's why I agree completely with Martin Aspeli's comment about the driving force needing to be at the users, integrators and businesses end. To me, an evolutionary path sprinkled with revolutionary ideas would be wiser than a complete break and rebuild strategy.
One last comment about starting from scratch: even a complete clean slate restart is no piece of cake to get right. The Django web application framework was started from the ground up by another group of talented Python developers and was in controlled use for some time in a production environment before its authors decided to open it up for the world. Not very long after going public, a drastic refactoring of some parts was deemed necessary (the so-called magic removal branch), to "remove warts that Django had accumulated over the years".
In Django's case, I think that refactoring was done early and worked fine, but the point is it was a fairly well controlled project and they still needed to remove warts. I doubt they could get away with something like that at this time. They have too broad an user base for that at this point. Books have been published, tutorials written, sites launched...there's no going back now.
I think Malthe would do a great good to the Plone community if he pursues his ideas and contrasts his approach with Plone frequently, so that some of his work can be integrated with the Plone core at some time. Vudo is a good name, I'd say. For better or worse, let Plone be Plone and continue its evolutionary path.
Previous Topic
