Are we rewriting vBulletin?
Yes, we are rewriting vBulletin. The current code base has served us well, but it's now time to rebuild it.
This task is enormous. The current incarnation of vBulletin has roughly a quarter of a million lines of code and took many tens of thousands of developer-hours to produce. Re-implementing its rich feature set, complex business logic, and years of bug fixes and tuning is a huge undertaking. The upcoming 4.0 release represents the beginning of that process.
4.0 will not be a complete rewrite, but the 4.x series will be, and the first wave of refactoring to ship with 4.0 will cover aspects of multi-content search, attachment management, style management, presentation design and more. Additional components will be refactored with each subsequent release.
Additionally, the 4.0 release will introduce some major new customer-requested features, like CMS, ad management, and some key SEO features. For those who use highly customized templates, there is also a greatly enhanced utility for diffing and merging them to make future upgrades much easier than they've been in the past.
The features we include are in direct response to customer requests, most of which come from the vBulletin community forums. Do we cover all requests? No, of course not. There are hundreds of requests, so our approach will be to address them in priority order. While everyone has slightly different priorities, we'll use our best judgment in choosing which features come next. These will be hard decisions, but I think we can get it mostly right, most of the time.
Why will vBulletin be rewritten incrementally instead of all at once?
With a team of eight engineers, a complete rewrite is no less than an 18 to 24 month project, and that assumes that no new features are added in the process. This is a competitive market, and two years is a very long time to go without new feature releases.
There are two primary reasons why we have chosen to approach the rewrite incrementally rather than as a big-bang, all-at-once proposition:
-
Responsiveness to community feedback We base our product development decisions on the suggestions, critiques and debates on the forums. We've heard loud and clear that (almost) nobody is willing to wait years for improvements to be rolled out. Moreover, the more frequently vBulletin is released, the sooner we hear your feedback, and the faster we can respond to it.
-
Predictability. We hear loud and clear that vBulletin users want a predictable release cycle you can depend on. While in theory a clean-slate rebuild sounds good, the reality is that large-scale software rewrites are mine fields that are notoriously difficult to plan and execute.
Breaking the work into smaller, more frequent releases makes our estimates more accurate and ultimately yields a higher quality product. It also somewhat lessens the risk that the new architecture will hand us ugly surprises, such as new performance issues we hadn't seen before. (A very real problem, since such surprises nearly always surface in rearchitecture projects.)
And yes, even radical rearchitecture can be done incrementally.
The main differences are that:
- there will be incremental releases along the way, rather users having to wait the full two years to enjoy the benefits of our work
- what was previously called "4.0" now is now more accurately the "4 series"
The overall time frame for the rewrite is about the same as previously expected, probably on the order of two years, as James stated previously.
Are there any plans to rework vBulletin.org?
Short answer: Not immediately. In the short term, we will be focusing our energy almost entirely on building 4.0. However, a lot of ideas for vbulletin.org are being discussed, and when we're ready to formulate more concrete plans, we'll open them up for discussion.
Where do you see vBulletin after 2 years when 4.0 development cycles have been completed? Still a forum solution or a complete site solution which offers enterprise solutions to customers?
The addition of CMS moves vBulletin a big step toward being a site-wide solution. Architecturally, vBulletin's 4.x series will move into an MVC framework, with cleaner object-orientation and more elegant relationships between components. 4.0 will include some small steps in this direction, but subsequent releases will introduce major rearchitecture. New architecture requires changing all kinds of things--everything from how we think about performance to how third party plug-ins are developed. Those aren't yet close enough to elaborate on, but we'll communicate well in advance.
How many months are expected to separate two different generations?
We want to take advantage of the rapid feedback cycle that comes with more frequent releases, so my best projection today is that we will try to release roughly every six months, though we will adjust this as it makes sense to do so.
I hope the CMS is a powerful tool that will enable us to create almost any type of site we want (i.e. like Drupal) as opposed to being a simple static page CMS.
Drupal is a robust, mature product, and it's not possible to match it feature-for-feature in our very first release of CMS. However, it will be more than simple static content management, and I think you'll be pleasantly surprised with the features we have included. Please remember that the first release is just the beginning, and if the features you want aren't there yet, they may appear in future releases if there is popular demand.
Will it still be a MVC system?
Yes - We intend to achieve our ultimate goal of a complete architectural refactor of vBulletin over the course of a number of vBulletin 4 releases. This allows us to get fresh new code out much faster and be more responsive to your needs.
What about Private Conversations?
vBulletin 4.0 will not include any changes to the private messaging system, however this system will be reworked in a later release.
Will there be a new AdminCP?
Many of the new features will include new admin control panel areas, however full scale reworking of the AdminCP will be included in a post-4.0 release.
Now the SEO feature...is it just going to be friendly URLs?
The SEO features will include friendly-URLs, a new approach to handling duplicate content and markup designed to be easily interpreted by search engine spiders. SEO will be built into vBulletin.
Is this all the information we're getting before a beta of vBulletin 4?
Leading up to the beta there will be better, more frequent and more open public communication about our development process. This first announcement sets the scene and provides a broad outline of our plans for vBulletin 4. Detail about individual features and development approaches will be explored though blog posts. |
