Product SiteDocumentation Site

Chapter 5. What your business does correctly when practicing the open source way

5.1. Identifies and focuses on key future technology
5.2. Funds key open source development
5.3. Makes mistakes and learns from them
5.4. Is daring about applying the open source way to non-engineering teams
5.5. Works hard to preserve culture in a fast growing company
5.6. Takes people who think they understand the open source way and really teaches them how it works
5.7. Has a strong brand and steers that consistently through community interactions at all levels
This chapter is a pat on the back for what you do correctly.
It is also your reminder -- don't forget to keep on doing these parts that work well.
Continuous improvement means we are always building on what we have learned before. It is not a single state that you achieve to remain static.
For example, the course of the Fedora Project as a source for a Linux distribution demonstrates the spirit of continuous improvement in the open. Simply converting the community Linux distro to a non-commercial project was not enough. It took six releases of Fedora to get over the hump of enabling the wider community to contribute without inhibition or barriers.

5.1. Identifies and focuses on key future technology

The technology you defined two years ago, perfected a year ago, and are making money on today, is going to be a commodity a year or two from now. This is one constant we can rely upon.
Open source communities force your organization to keep moving, to never get comfortable in one spot for too long. This is an effect of the rapid way open source software can advance, and it works to your advantage to always have little brothers and sisters nipping at your heels.
Early in the 2000s, Red Hat provided the industry's best system management for Linux via RHN. Because that project was internal only and so was limited in its future by exactly how many people Red Hat hired to work on it, there was a natural limit to how long RHN would remain in a leadership position.
Although arguably Red Hat was able to keep RHN relevant for an additional few years by not engaging in external system management projects, the resulting situation in 2009 is quite opposite. RHN has now drifted backward in relevancy compared to open source alternatives, and the open source tools far outstrip RHN capabilities where it matters the most to customers.
The technologies in the best position to replace RHN include Nagios, Puppet, Cobbler, Func, and Yum -- the first two were started by Red Hat engineers and maintain strongly influenced by Red Hat needs, while Yum was made successful by being the better and open dependency resolver that the RHN tool 'up2date' was not. It took a few years longer in this case, but Red Hat is getting to the next level by re-focusing on the key technology.