Big Changes Ahead for Red Hat

By: Dee-Ann LeBlanc
Monday, July 21, 2003 10:32:25 AM EST
URL: http://www.linuxplanet.com/linuxplanet/newss/4913/1/

Opening Up the Red Hat Development Model

Massive changes are coming to a red fedora near you. For a number of reasons, Red Hat Linux is now moving to a more open development model with less focus on boxed sets and more focus on community involvement. The announcement, which was partially leaked this weekend, was made official Monday morning by an announcement from Red Hat's Bill Nottingham.

The announcement details some big moves for the way Red Hat Linux is developed, but does not confirm information also leaked this weekend that Red Hat plans to drop its retail line of shrinkwrapped, boxed software.

No more closed beta teams for the regular Red Hat releases. No more having to deny feature requests due to various time constraints, being unable to apply last-minute updates to a new release because it takes a month for CDs and boxes to go through the production process, or keeping people who truly want to help make the distribution better at arms' length.

In fact, the latest Red Hat Linux is going to be released under this new model. Or at least part of it.

Aside from the issues mentioned earlier, there's also a general retail problem with releases every six months. It's hard to keep stores up to date with the latest versions, and most people using the distribution don't actually purchase the boxed set from retailers. This makes it even more touchy to try to get stores to stock it and deal with the turnaround and so on. For more on what's happening with the retail product line, we'll have to wait until the release of the product launch plan in the fall.

Another timing issue was additional alpha and beta cycles. When you have to meet retail deadlines, you must either print up the materials and ship them on time, or pay the price. This problem gets in the way of adding another development cycle if things aren't quite working as well as Red Hat would like. Erring on the side of stability. The games industry could learn something from that.

A third reason addresses one area of frustration for some Red Hat employees: an inability to really let people get involved in the development process. I can attest from being on the beta team that the folks from Red Hat get "virtually" beaten up pretty regularly by people wanting this or that feature, fix, or whatever. Often it's over an issue they don't even control, and that can't make for a happy life.

Life Gives You Lemons, Make Lemonade

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.