The Source of All Good Bits

by Timothy Prickett Morgan

Writing good software that real people can use and that is reliable is a lot harder than writing a decent novel, play, or screenplay--and we all know how terrible most of those forms of entertainment really are. There's a reason why, for instance, the English-speaking peoples of the world have been studying Shakespeare for four centuries, and will probably be doing so for another four. And with the possible exception of Solitaire, maybe Tetris, and just possibly Excel, I would venture to say that no one in the future will look back at the computer programs we create today in quite the same way as we do the works of Shakespeare.

While both plays and computer code involve writing, any similarities between the two end there. It is a lot easier to get a job writing code than it is to write plays, and some days, it really shows.

Despite the enormous amount of energy that goes into creating and maintaining the software that quite literally makes the human world go around--gravity is still responsible for making our planet spin on its axis and rotate around the Sun, thank heavens--and while Nature seems to have got her programming down to lean-and-mean, error-free code, our software still sucks. And while the industry goes on and on about the proliferation of five dozen open source licenses, the benefits of open versus closed versus shared source, shareware and freeware versus commercial products, and other similar holy wars, I think most of us would agree that while our computers are very sophisticated and vital to both our personal and professional lives, software doesn't work well together. This is a serious problem, no matter what the source of the source code is.

Don't get me wrong. I am impressed with the progress that the Internet--which is arguably the only important computer platform these days, regardless of operating systems and server platforms--has allowed. We can all do things that were not even possible a decade ago, and whole new kinds of businesses, usually centered around some sort of community, have sprung up and challenged our conceptions about what a business is and what customers are, about what a community is and what the power of participation is. This is all healthy and good.

What is not healthy, and what is not good, is for the IT industry and the companies and consumers who use IT products to get bogged down in holy wars. I am, like many of you, a strong advocate of open source technologies. Not because I think I have a right to see someone else's copyrighted code and make modifications to it, either. I like open source because I believe an open development model, based on a meritocracy among a small group of very smart people who know what needs to be done to improve the product and who have a large pool of enthusiastic beta testers, is the best way to create code. This is and always will be, in my opinion, a better way of creating code than a vendor succumbing to the temptations of creeping featurism to try to stimulate an upgrade cycle and the next round of sales.

Because I believe in open collaboration between users and developers that spans corporations, customer involvement in requirements definitions, and transparency in roadmaps, I have naturally been attracted to open source software. I have argued that in an ideal situation, key technologies, such as the Java programming language and its virtual machine environment, should be open source and under the guidance of the best minds and users in the Java industry--even those at Microsoft. Whether Sun Microsystems wants to admit it or not, C# and the Common Language Runtime is a fork off Java and its JVM--and Sun caused that fork by holding onto Java too tightly. Innovations should not have to be arbitrated by any single vendor, even if it Sun, which has been very generous in other areas when it comes to open source (notably, with the open sourcing of its Solaris operating system earlier this year), has our best interests at heart. You have to trust community, and Sun knows that.

As a user of computers--and not just a personal computer user, but a business person with servers and customers who are dependent on what those servers do--I am by no means a purist when it comes to open source. I have adopted many open source technologies because the IT people I employ know them best and respect them most, but also out of necessity, since the economics of key open source technologies are attractive--free or damned near free relative to proprietary solutions, in many cases.

But that is not in any way to say that I am opposed to closed source. I have plenty of closed source software I use, some of which works very well--most of the time. I was an early beta tester for many generations of Windows programs from Microsoft, and I loved seeing Microsoft give Unix and proprietary environments a run for the money for the past decade. The greed and sloth of one generation of IT products generates the hunger and energy of the next, from mainframes, to proprietary minis, to Wintel PC servers, to Lintel boxes and a stack of open source software today. But that trend line is an over-simplification, and one that does no justice to the hard work that a lot of IT players--those working for big corporations like Microsoft or for tiny open source projects located on SourceForge --have put in over the years to try to improve software.

But there remains a lot of work to be done, and the IT industry--meaning the companies that make IT products, the communities that make open source alternatives, and the companies and consumers that buy or use their products--have to raise the bar, they have to make it possible for open source, closed source, freeware, and any other kind of software (such as a subscription-based service) to not only interoperate, but do so smoothly and effortlessly.

While there are plenty of people with axes to grind in the open-closed source debate, it is time to admit that what we are arguing about here is not time and money--brains and the bucks those brains are worth--but rather a need to raise the quality level of software of all kinds. If this industry needs a standards body, it is one that will police APIs and ABIs and document the interoperability of these interfaces such that programs of any kind can work together. The focus of this industry is on operating systems, platforms, compilers, and competing runtime environments not just because these are important, but because they are easy to understand, and it is easy to put competing forces into camps. That doesn't mean this is where we should focus. It just means that this is where we do focus.

To my way of thinking, open source software is just a product that I will eventually pay for through a support contract when I use it in such a way that I feel I will need a throat to choke when something invariably goes wrong, but which allows me to get support through a community for free if I cannot afford such professional support or if I am too cheap to pay for it even if I can afford it. Closed source software is about having professionals create programs that we are willing to pay to support, and to do so upfront. We are arguing about when we pay, and how much. This is not the real argument. Not matter what, we will pay. Of this, there can be no doubt, since every minute of our lives is worth money. Supporting yourself costs time, and that is money.

What we need to be arguing about are different kinds of things. I will offer two examples, but there are undoubtedly many more.

First, we need laws that require APIs and ABIs of all programs--open or closed source--to be publicly documented so any programmer can figure out how to make any two programs interoperate. In plain English: If you have an undocumented API or ABI in your code, you go to jail. Is that simple enough? Programmers should not have to join a cult (which is what most vendor developer programs are) or become involved in a platform or source holy war to make two programs work together.

Second, because commercial software providers actually make a living selling software or support (or both), they should be legally obligated to use the money they receive to provide adequate and timely support and to further document the reliability and interoperability of their products. There should be international standards for software, and there should be economic consequences of not meeting these standards. Bad software is a kind of economic pollution. The standards would apply to commercialized open source projects like Linux, JBoss, and MySQL as much as they would for products from IBM, Oracle, and Microsoft.

With people, it is not how open or closed you are, but how well you work with others that really matters. Software is no different.