Synchronicity and Sharing
By Andrew Price, 2008-05-18 17:46:54 in General.
Dag Wieers' comments that "Mark Shuttleworth's recent pledge to join a synchronised release plan for Enterprise Linux distributions is no more than a wish to benefit from a lot of work that Novell and Red Hat are already doing in the Enterprise space" are strange.
There is one main reason why I think this is a strange way to argue against Mark's idea and it's this: Red Hat is a very successful company based upon the idea that there is value to be found in and around software which is freely available to modify and redistribute. This is a cornerstone of Red Hat's business model and thus any calls of "It's not fair to use the [freely available, modifiable and redistributable] products of Red Hat's efforts for your own profit." (my words, not Dag's) seem quite out-of-place.
Sure, Canonical is a tiny company by comparison, so it doesn't have a large workforce to make a huge number of upstream contributions, and it's not yet profitable so it needs to be clever in order to propel itself towards sustainability. But if anybody thinks that synchronizing release cycles to stabilize versions and focus efforts across distributions would not benefit Red Hat more than the added competition might damage their business, they might need to rethink the situation. But I guess this is the main question that Red Hat needs to ask itself before signing up to Mark's idea.
One thing Red Hat and Shuttleworth have in common is that they're good business players. They seem to get the idea that, whatever boosts the success of Linux-and-friends as a whole is good for expanding the Linux-and-friends market and other companies' opinions of it. Currently one of the factors holding back adoption of Linux-based solutions, from the point of view of potential customers, is that there's so much to choose from; so many distributions, packages and support possibilities. Judging from one of Red Hat's recent successes the deal clincher is the quality of technical support which is on offer. Technical support in this context presumably means killing bugs and making sure that hardware support for the deployments is top-notch. So having some kind of consistency between versions might make open source a larger target for enterprise customers and hardware manufacturers (two groups which are not distinct) and focus development and testing efforts onto those versions.
So it's really a level playing field. Whatever Canonical contributes to free/open source is available for Red Hat to benefit from and vice versa. The bad vibes I've been sensing lately (particularly surrounding the kernel) seem to be rooted in how Canonical isn't big or successful enough to contribute on the same scale as Red Hat yet. That's to be expected, for now. In reality, any business which enters the Linux distribution market really should know that the competition ultimately is not about having better software than the other guy, because the software belongs to all of us and none of us. The winner will be the company with the best people and the best business ideas and strategies. To me, Mark's idea is not one which is meant to give Canonical an advantage over other companies (especially an unfair advantage), it's an idea meant to map the century-tested assembly line approach which made Ford so successful onto the main components of several Linux-based distributions to push them all forwards. Whether it's a good, workable idea or not has yet to be tested, but I think it would be an interesting experiment.
Comments
web123 writes:
> Whether it's a good, workable idea or not has yet to be tested, but I think it would be an interesting experiment.
http://en.wikipedia.org/wiki/United_Linux
- "United Linux was an attempt by a consortium of Linux distributors to create a common base distribution for enterprise use, so as to minimise duplication of engineering effort and form an effective competitor to Red Hat. The founding members of United Linux were SUSE, Turbolinux, Conectiva (now merged with MandrakeSoft to form Mandriva) and Caldera Systems (later renamed to The SCO Group). The consortium was announced on May 30, 2002. Its end was announced on January 22, 2004."
http://en.wikipedia.org/wiki/DCC_Alliance
- "The DCC Alliance (DCCA), was an industry association designed to promote a common-subset of the Debian-based Linux operating system that multiple companies within the consortium could distribute.
[...]
Membership remained open to additional organizations with an interest in Debian-based solutions. The most visible abscent from any involvement was the Ubuntu distribution backed by Mark Shuttleworth and Canonical Ltd. who declined to join the Alliance. The Ubuntu founder, Mark Shuttleworth stated in 2006 that he did not believe that the DCC Alliance had any future"
https://lists.ubuntu.com/archives/sounder/2006-January/003630.html
Mark Shuttleworth :
- "But it strikes me that this approach has never worked in the past. In fact, every distro ALWAYS modifies elements of the core, and with good reason. And while we would love that not to be the case, the truth is that the reasons to specialise outweigh the benefits of homogeneity."
Well said Mark Shuttleworth !
2008-05-18 20:14:00
web123 writes:
And LCC (Linux Core Consortium).
http://lxer.com/module/newswire/view/26557/index.html
- "We're very pleased to announce that Connectiva, Mandrakesoft, Progeny and Turbolinux today announce the creation of a common implementation of the LSB 2.0 which will serve as the base for future products. The project, called "Linux Core Consortium" (LCC), is backed by Linux supporters such as Computer Associates, HP, Novell, Red Hat, Sun, OSDL, and the Free Standards Group."
Red Hat never supported LCC but the LSB.
2008-05-18 21:56:49
Andy writes:
web123: I'm not entirely sure what you're trying to get at. Those historical cases don't have anything to do with the simpler idea of synchronizing release schedules. Perhaps you'd like to make your comment more obvious so readers know what your point is.
2008-05-19 03:35:20
web123 writes:
> Andy writes:
> web123: I'm not entirely sure what you're trying to get at. Those historical cases don't have anything to do with the simpler idea of synchronizing release schedules.
If Ubuntu wants to release the next LTS at the date of the next RHEL or SLES, them Ubuntu just need to delay its release until the release of the next RHEL or SLES :-)
Perhaps you have not carefully read the Mark Shuttleworth's blog.
http://www.markshuttleworth.com/archives/150
- "And it’s not just Ubuntu that does regular 6-month releases, Fedora has adopted the same cycle, which is great because it improves the opportunities to collaborate across both distributions - we’re more likely to have the same *versions* of key components at any given time."
- "And in the third wave, we’d have the distributions - Ubuntu, Fedora, Gentoo, possibly Debian, OpenSolaris. The aim would be to encourage as much collaboration and discussion around component *versions* in the distributions, so that they can effectively exchange information and patches and bug reports."
2008-05-19 04:44:35
john writes:
"Whatever Canonical contributes to free/open source is available for Red Hat to benefit from and vice versa"
Except Ubuntu has almost no upstream contributions worth talking about (upstart was done on one of the employee's spare time) and most of their employees are working on proprietary technology like launchpad and landscape. If someone proposes something like this, they shouldn't have hidden agendas IMO.
2008-05-19 10:30:27
Dag Wieers writes:
I personally don't have anything against Ubuntu using the backports and fixes that Red Hat is paying for. That is in fact what Open Source is about.
What I am saying is that I think Mark's position is quite naive and that there is an ulterior motive to this naive proposal. Ubuntu gains much more from a synchronized release cycle and it does not help Red Hat at all. In fact it would harm Red Hat's current model which allows the freedom to pick the best collection of application releases Red Hat can support.
What Mark somehow is ignoring is that Red Hat has selected only the software they can support for 7 years. If that means shipping a non-released, yet stable gcc they will. If that means shipping a firefox 1.5 with RHEL5 instead of firefox 2, they will.
It does not depend on a project's release cycle, it depends on what Red Hat's resources can support in the long term. It is a balancing act that every vendor has to do. And Mark's balancing act is to match its limited resources within Canonical with his desire to be successful in the Enterprise market (even if that means free backports to old kernels and applications).
It is not a coincidence he brings this up with the newer Ubuntu LTS release. Let's see if Canonical can support their LTS release for 5 years as well as Red Hat supports all of their releases for 7 years. Red Hat has proven they can do it without the need of a synchronised release cycle of Open Source projects.
2008-06-11 23:35:32