Linked by Thom Holwerda on Mon 19th May 2008 18:40 UTC
Back in April 2008, Canonical's Mark Shuttleworth pitched the idea of major open source projects synchronising their release cycles on a 6 month period. Projects like gcc, the Linux kernel, GNOME, KDE, as well as the distributions, would work out an acceptable release schedule. It would allow for easier collaboration between the various projects, and hardware vendors would be better able to support Linux since all major distributions would ship with the same kernel version.
Permalink for comment 314875
To read all comments associated with this story, please click here.
Getting big in terms of users or consumers is very different from getting big in terms of upstream contributions. Unless you have a lot of upstream contributions, you can't really drive it strategically in the direction you would prefer. Red Hat only has the ability to support critical infrastructure for customers because it contributes heavily in that area
The more critical it is, the more contributors you need and that's why you see Red Hat as the largest contributor the Linux kernel and employing maintainers of glibc, gcc, many of the GNOME components etc. This isn't charity. It just makes business sense to do that if you are making your money selling services around Free and open source software. Since you can't lock in your customers, this is the real way to provide value (unless you want to mix and match with proprietary software in between which is rather tricky to do if you are building a community).
If Canonical wants to drive sync release schedules, it can't merely hope to float the idea and get everyone to agree. Contributions in the ground level is what earns the trust of the community to actually listen and help. Pick and choose what is considered as critical for your distribution and employ people or sponsor people already working on those areas.
Member since:
2005-07-06
Getting big in terms of users or consumers is very different from getting big in terms of upstream contributions. Unless you have a lot of upstream contributions, you can't really drive it strategically in the direction you would prefer. Red Hat only has the ability to support critical infrastructure for customers because it contributes heavily in that area
http://fedoraproject.org/wiki/RedHatContributions
The more critical it is, the more contributors you need and that's why you see Red Hat as the largest contributor the Linux kernel and employing maintainers of glibc, gcc, many of the GNOME components etc. This isn't charity. It just makes business sense to do that if you are making your money selling services around Free and open source software. Since you can't lock in your customers, this is the real way to provide value (unless you want to mix and match with proprietary software in between which is rather tricky to do if you are building a community).
If Canonical wants to drive sync release schedules, it can't merely hope to float the idea and get everyone to agree. Contributions in the ground level is what earns the trust of the community to actually listen and help. Pick and choose what is considered as critical for your distribution and employ people or sponsor people already working on those areas.