2006/5/30, Jonathan Lambert <j@firebright.com>:
[...]
There are a number of ways that OS Projects and Organizations can cope with change. But they are strategic compromises in investment vs return. If you look at this not from a developer's perspective, but from an investor's for a moment, you'll see that often these users see Open Source systems as a strategy instead of an approach. From an investor's point-of-view, the decision to use an Open Source platform for your development is the decision NOT to use a commercial alternative. And part of this compromise is inherently (on the little checklist of OS VS Commercial that business people like to make) to embrace this rapid development cycle of OS, be it Linux, eZ or Drupal. It's actually in vogue to consider the rapid speed of revision a technical and commercial advantage! If you need a 5 year support horizon, which many organizations do, then you shouldn't be using an Open Source CMS. You should be using Redhat, or IBM, or one of the big CMS vendors.
Commercial organizations are paid to keep their support organization going for versions of their software that are put into production. Open Source projects cannot afford to dedicate the resources to doing so, nor is it really in the best interest (or interesting) for the user community to do so. If you need long support horizons, use a commercial product.
So, the idea of clinging on to a release that is already past is absolutely terrible. It works backwards from what you are claiming to want to achieve – i.e. a sustainable user community and happy consumers of the product, and lower overall costs (it's false economy to think so). Absolutely the only person it benefits is the consultant who's doing the work. And nobody ultimately benefits. The people who stay on the version end up on a "fake fork", the user community may get materially fragmented, the users end up with a "tough luck pal" response from the community for support, and good developers end up sidetracked on projects that do nothing to drive the platform forward and in fact generally damage everyone involved with them. Sometimes tremendously... [..] Dries has already laid down the word on this, and I agree with his approach. Let's make the archives available (they are), but not spend any time on it. Customers who are on the platform should know the risks of using an Open Source platform. And if support is really needed, it should come from the community of users/addicts.. If this is a serious issue, I would post to the Drupal.org site some content that will help people understand what they are taking on with an Open Source platform, i.e. Rapid integration, many upgrades, and relatively continuous integration projects as new tools (like the forms api) are released. I also back Laura's doc (nice approach!), who said it mighty well and whom I work with and respect.
Please, let's move on.
Thanks Jonathan, it's a clever summary. It's time now this thread stops. Regards