Linux has reached a high level of maturity when it comes to enterprise-level features. But who decides what features they should be? At the moment, it's mainly the developers, many of whom have commercial axes to grind on behalf of their software house employers. While the open source community is moving in the right direction, there's still more to do in this regard.
Linus Torvalds recently announced that software developers making contributions to Linux would have to "sign their work" and "vouch for its origin" via a Developers Certificate of Origin. Torvalds claims that the Developers Certification of Origin is needed primarily as a trail of documentation that makes developers accountable for the code that they write for Linux. In other words, there is a need to associate code with a contributor.
This announcement is driven primarily by the SCO lawsuit against IBM. However, it's likely that corporate enterprise users would have eventually requested something like this anyway, regardless of the SCO lawsuit, as Linux moves more and more into the enterprise. It just happened quicker because of the lawsuit. Corporate users do not want the uncertainty of facing intellectual property (IP) lawsuits if they use open source software. When they buy a product, they want to know if there is open source software in it and sometimes they want to know the origin of the software.
Many companies now ship products with open source code in them. It could be Apache bundled with a system, or it could be Linux in large HP printers. I know of one case in which a buyer requested that open source code be removed from the software that he was buying. I think that is an exception, but some buyers are worried about the SCO lawsuit and accountability for code.
The procedure for adding code to Linux has been relatively informal and on occasion lacking documentation. Many enterprises have become accustomed to this practice because the software that has been produced by open source projects, like Linux, is of very high quality.
Today, the Linux development process generally works as follows. Individual developers own various segments of Linux code. These developers are well known (to the Linux community) and trusted by Torvalds and other open source developers. A code owner generally controls what new code and functionality are added to the code for which he/she is responsible.
Proprietary software vendors have schedules for releasing software, even though they dont always attain them, a procedure for collecting features/functionality from their users, and letting users know what features will be in the next release before the release is made available. There's also documentation for the release.
Corporate users want the same thing for Linux and open source software. Note that this is not to say that the core development process of open source software should be like that of proprietary software.
The schedule for Linux is now better advertised than before, the features in a release are available well in advance of the release, and documentation has improved. Yet while proprietary software companies do not always add requested features into a release, there is a standard process for requesting them, irrespective of the size of user or how influential they are. Where Linux is still lacking is in the collection of features from end users.
If a large corporate would like to see a feature incorporated into the next release of Linux how do they get it included in the potential feature set? Do they have to have to hire a Linux developer who is accepted by the Linux community to go forward and lobby for the feature to be included in Linux? Do they work through a Linux distributor such as Red Hat to lobby for their feature? Do they try to find a work group at OSDL that is related to their needs? The answer could be any one of the above or none.
Today, large systems vendors, Linux distributors, some infrastructure ISVs such as Oracle or CA, and a few other Linux developers determine the feature sets for new releases of Linux. These influential groups have their own agendas because in many cases they are competitors. OSDL has done a good job trying to recruit new members from the business ISV and end user communities for its work groups where features can make their way into Linux, but the bulk of the OSDL members, especially those with influence, are not end users or business ISVs.
So who is going to work with large end users, many of them switchers from proprietary systems who use Linux to run mission-critical applications? Most will have no staff with insight or input onto core Linux development. If Linux were a proprietary operating system, they would make their requests to the vendor. But who do they make their requests to for Linux and who will listen?