Greetings all,
For those of you whom I haven't yet met by phone, chat or email, I would like to make a brief introduction and respond to some of this threads lively discussion.
My name is Ray Morgan, and I joined Internet Brands in September (minus a recent planned hiatus) to work full-time with Jelsoft on the development of the 4.x series of vBulletin. My time is devoted entirely to vBulletin, and I'm commuting every few weeks between Jelsoft's office in Pangbourne, UK and Internet Brands in Los Angeles.
For those who were curious about my background, I've been developing commercial software for more than twenty years and worked exclusively in the internet space for the last ten, most of those on large-scale commercial sites. My role in connection with vBulletin is a mix of product management, process engineering, project management and architecture.
A few of you have raised some valid questions about how (and why) the approach to vBulletin development has recently changed, and what the implications are. I'll try to clarify below.
Will we rewrite 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.
While, as James and Kier stated, 4.0 will not be a complete rewrite, 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 theyve been in the past.
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:
The main differences are that:
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.
While we know that we can't please 100% of users 100% of the time, Jelsoft and Internet Brands are deeply committed to providing vBulletin users a product they will love, and every decision we make is driven by that mission.
For those of you whom I haven't yet met by phone, chat or email, I would like to make a brief introduction and respond to some of this threads lively discussion.
My name is Ray Morgan, and I joined Internet Brands in September (minus a recent planned hiatus) to work full-time with Jelsoft on the development of the 4.x series of vBulletin. My time is devoted entirely to vBulletin, and I'm commuting every few weeks between Jelsoft's office in Pangbourne, UK and Internet Brands in Los Angeles.
For those who were curious about my background, I've been developing commercial software for more than twenty years and worked exclusively in the internet space for the last ten, most of those on large-scale commercial sites. My role in connection with vBulletin is a mix of product management, process engineering, project management and architecture.
A few of you have raised some valid questions about how (and why) the approach to vBulletin development has recently changed, and what the implications are. I'll try to clarify below.
Will we rewrite 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.
While, as James and Kier stated, 4.0 will not be a complete rewrite, 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 theyve been in the past.
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 this forum. 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.
While we know that we can't please 100% of users 100% of the time, Jelsoft and Internet Brands are deeply committed to providing vBulletin users a product they will love, and every decision we make is driven by that mission.