Rather than bemoaning these facts, Red Hat has decided to adapt their business model accordingly. The good thing about changes like this is they give you the chance to implement other new things you've been considering, but didn't want to shake things up to do. If the boat's already rocking, it might as well roll.

For starters, community participation will be possible from the ground up in the next release cycle. Traditionally, there is a beta team under strict NDAs helping to test the initial releases before they go public. Then there are the public betas, and then there's the "gold" release itself.

Things will change in a steady pattern. The upcoming release ("Cambridge") will come out under the new policy, or at the very least under a version of it that might be refined later. Rather than having development discussions on an internal Red Hat mailing list, they will be open to the public. Developers interested in working with Red Hat on this new direction--including developers who've been wanting to have their packages included but haven't been able to for space requirements or other reasons (aside from legal)--will be asked to hang out on particular IRC channels. The assumption is there will be some kind of schedule involved there. At this point, that detail hasn't been shared.

After this, non-Red Hat developers will be able to work with Red Hat to include their packages and still be the maintainers, without having to "hand off" their work to Red Hat in some overly formal manner. They official maintainers would be the ones to receive the bug releases on their own packages, reducing the occasional arguments over whether a bug report should be send to Red Hat or the package developer--and since the package developer was the one who made the RPM in the first place, this should work out well.

Exactly how and when all of this this will happen hasn't been decided yet. These decisions, again, will be made through public discussions. The upcoming release might include a test run of this process but there will have to be an infrastructure in place of some sort before moving into full production mode, otherwise chaos might ensue.

Another upcoming feature--though not likely for the version now in production--will be the ability to make third-party collections of RPMs that don't ship in the distribution itself. This would make life a lot simpler for folks looking for new software, and perhaps save the complaints that Red Hat doesn't come with "everything" like some other distributions. Projects like FreshRPMS (www.freshrpms.net) and Fedora (www.fedora.us) should benefit directly from this, and in fact there may be some cross-pollination between these groups.

While it might sound like this will become a free-for-all, that's not the case. Red Hat employees will have "editorial control" over the project. There will be objectives to focus on, and the folks at Red Hat will still have to make big picture decisions. For example, there's the legal problems with some packages. Shipping Red Hat to play MP3 out of the box is still too touchy a territory for a US-based company. So is DeCSS, which would allow playing DVDs.

"We just want to allow like-minded people to work with us on things that are a priority for them and others but might not be Red Hat's current development priority, as long as they are still in sync with overall objectives," says Michael K. Johnson at Red Hat. After all, this current direction means Red Hat will be free to be less conservative about what packages they include.

And to anyone who's cursed the company for not having the latest release of OpenOffice.org available for updates, or not adding their favorite Web log analyzer, that can only be a good thing.

Dee-Ann LeBlanc has 11 books and over 80 articles in print, and so much more. Check out http://www.Dee-AnnLeBlanc.com/ for more details.

« Back: Opening Up the Red Hat Development Model