GPLv3: Innovation will Trump Narrow Agendas

The hullabaloo surrounding the current GPLv3 debate makes for great theater and good cocktail conversation, but it is unlikely to create any real serious trouble for Linux or the open source software movement. Any extreme attempts to promote a narrow agenda will be crushed by the greater weight of our collective craving for innovation. A simple historical case study serves as a great example of what happens to narrow agendas that stand in the path of the relentless march of innovation.

In August of 1997, a group of disgruntled compiler developers forked gcc2 because the FSF was no longer responsive to their needs to innovate. FSF had a "stability" agenda around the compilation of C code for GNU. The Cygnus crowd, Linux crowd, and other constituents of gcc2 needed innovations to promote their products that were not being accepted by FSF. They forked gcc2 and created the Experimental/Enhanced GNU Compiler System, EGCS (pronounced eggs). They proceeded forward with innovations that were important to their user base, and they left the FSF branch of gcc2 behind.

In April, 1999, FSF abandoned their branch of gcc2, and re-united with the EGCS crowd because their branch had become largely irrelevant to users because of their narrow agenda. In less than 2 years, the agenda of FSF was buried by the greater good because of the original license innovation of the FSF, the GPL. The GPL allowed the EGCS crowd to create the branch that ultimately became the trunk of the code tree because they were delivering value to a broader constituency than the FSF compiler maintainers.

I believe the same scenario will play out with GPLv3. If the FSF attempts to promote a narrow agenda with the new license, all the code that is created under that license will be marginalized and the competing branch that continues under GPLv2 will become the trunk of the tree. Ideology and agendas are the stuff of interesting theater and intriguing cocktail conversations. Large scale adoption of innovation is what makes our lives better, and narrow agendas that stand in the way of a good life quickly become marginalized.

Golden Bits or Fool's Gold

One of the more popular open source business models is the "golden bits" model. In this model, the term "certified" or "certification" comes up often during the sales cycle. But what does "certification" really mean?

Generally it means that there is a 100% probability that a certain configuration of technology has passed a certain set of tests. Unfortunately, the probability of that technology configuration matching your system preferences multiplied by the probability that the test cases mirror exactly your application workload is equal to 0%. This reality explains why IT shops that only buy "certified" solutions, open source or not, still have four layers of application promotion: development, test, QA, and production. These layers are required to "certify" that the "certified" solutions will actually work for the customer. It also explains why the services segment of the IT industry is the largest by a significant factor, even in the face of so many "certified" solutions.

The problem with "golden bits" is that gold is useful for certain things like jewelry and corrosion resistant electrical contacts. But, for example, carbide steel is better for milling and drilling. Diamonds are better for making grinding wheels. It really depends on what you are attempting to accomplish with the materials you are provided. Fortunately, the current trends in the software industry are favorable to the needs of the customer with respect to software becoming more modular and malleable to workload specific requirements.

The first favorable trend is open source itself. With open source, at least you have the option of changing a particular component to suit your needs. It certainly requires an investment in skilled developers and software architects to carefully choose a sustainable path, but it is likely that this investment could be cheaper than the alternative -- being stuck in a technological dead end with the proverbial helicopter airlift to better ground as the only way forward. Be certain your open source vendor supports your needs to modify the components to suit your unique application requirements.

The second favorable trend is service oriented architectures (SOA). With SOA, integration among "loosely coupled" components occurs based upon a network access standard. Certification is irrelevant because the provider can run the "service" as a black box if the system software approach for a vendor's component is not consistent with the system software for components provided by the internal company developers.

The third favorable trend is server virtualization. With server virtualization, the system software that supports the application can be decoupled from the system software that abstracts the hardware and exposes the network. Each application component has its own operating system and related system software, and multiple components are integrated on the same hardware via a virtual machine wrapper. Certification simply means that each component can be delivered as a virtual appliance, which eliminates all potential for conflicts among components. Certification is real because the entire unit is integrated and maintained by the application provider. If it breaks, it is their problem.

"Golden bits" will never be a substitute for great software architecture. Be wary of any vendor hawking "golden bits" or "certification" because the reality is there are likely lots of hidden costs if they have not implemented a solid software architecture.