Andi Payn wrote:

On Thursday 06 March 2003 06:17, Adam Williamson wrote:


If the problem is contractual obligations, perhaps the 9.0 experience
ought to indicate that such contracts should not be made.



How do you propose that Mandrake release their software, then? If they wait until there is a stable release before signing contracts, it will be at least a month before that release hits the shelves, and even longer before most of the advertising supporting that release appears. And that's assuming that they have good relationships with everyone involved (and are willing to pay for "rush" work in some cases). You can't just call someone and say, "OK, our release is ready," and get it in stores the next day.


Now, in the long run, they'd still get out the same number of releases per year, it's just that there'd be a gap of a couple of months when they first switched to this new strategy. That doesn't sound too bad, but think about what it means--it means a couple of months with significantly reduced revenue, which isn't such a great thing for a company in Mandrake's financial situation (or, really, any company).

Plus, this means that the releases that people buy on the shelves would no longer be up-to-date. Part of the reason that people choose Mandrake over, say, Redhat is that Mandrake usually has state-of-the-art packages.

To people who switch from other distros, this is a huge difference. A friend of mine once asked, "Why should I bother upgrading to the new version of Redhat if I'll still have to install gcc and KDE myself to get recent versions?" I was able to point to Mandrake and say, "Look, they have them. Why not switch?" He did.

To people who switch from Windows, this may not seem like as big a deal--but it still makes a difference. For example, part of the reason that Mandrake 9.0 looked good to Windows users than the other distros was KDE3, and part of the reason it worked well for them was konqueror/galeon, evolution/kmail, and the various office packages--all of which had only recently become good enough to sell a Windows user.

In other words, Mandrake can't afford to have major releases that are two months out of date. But they can't avoid this unless they pre-schedule their releases and sign these kinds of contracts.

Of course some companies sign even larger contracts and start even larger advertising campaigns and then slip releases by months, anyway (Windows 97, anyone? Rhapsody 1.0?). But most companies can't afford to pay two or three times for each release, keep the release-time ad blitz up for months on end, and fight the bad PR. Apple can just barely get away with it; Mandrake certainly couldn't.

The way that software is released today stinks. It's bad for Mandrake--but it's also bad for Microsoft and Apple and Redhat, and for Symantec and Microprose and Adobe. Mandrake refusing to play by the same rules would not affect the system, it would only hurt Mandrake.





Andi, there is a solution to this problem. That is to maintain a stable version of cooker. Do the actual work of upgrading and fixing various components offline, and merge them into the stable cooker tree only when they have been thoroughly tested. In the mean time continually use bugzilla to QA the stable cooker tree itself. As it is, cooker is a collection of a gazillion efforts all attempting to take place simultaneously on the same codebase, and all attempting (or forced) to come to maturity at the same time. And even though the software is modular, there are cases where a problem with one component can jeoperdize a timely fix for another. The various efforts need to be delinked and individually debugged on a stable cooker. The existance of a stable thoroughly QA'd cooker would mean that Mandrake could pull the cord for a release at any time without risk of unforseen headaches.


Reply via email to