Section 2.2. Comfort

2.2. Comfort

Maybe you just want to do it yourself. Businesspeople in the industry who have grown up around open source often comment that duplication of effort, or "reinventing the wheel," is not time well spent. I rarely hear this from programmers. When people hear about KDE and GNOME, or Linux and BSD, or even more esoteric arguments about which window manager to use, inevitably someone will chime in, "Obviously, they had a lot of time on their hands. Otherwise, why would they have started from scratch?"

The implication is that the programmers have somehow wasted time. When I choose to reimplement some technology or program, I know what I'm doing, and even if it is a "waste" of time or duplication of effort, I think of it as practice. And when I can enjoy the luxury of implementing from scratch, I really like the results, because they're all mine and what I've developed works exactly the way I want it to.

2.2.1. But Why So Many of the Same Things?

Business, of course, is interested in productive developers, and productive developers don't rewrite things, right? No, not necessarily. People rewrite code all the time. The more-informed companies recognize that this type of thing is often inevitable, and the best and most resourceful encourage this kind of mental knife sharpening, because it leads to better developers and better code. Given the time, programmers often prefer to learn from other people's code without actually using the code, and if open source ends up as one big repository of example code, I call that a success.

Also, computers change. Computers, languages, compilers, and operating systems change so quickly that a periodic rewrite of some code becomes vital, from a performance perspective. To take advantage of the newest processors, architectures, and other advancements, a recompile will certainly be required and will likely expose issues with your code (architecture changes lead to this directly).^[4]

^[4] For example, you write a program on your handy laptop, you compile it, and it runs great. Later, you run it on your fabulous dual Opteron server. It crashes because you assumed an integer was 32 bits and the Opteron (running a 64-bit OS like Linux, of course) has 64-bit integers. This is a basic error that comes up in a lot of different ways during 32-64 bit transitions.

But people are using libraries, code, and examples from open source code, copying them into their codebases rapidly. Certainly this happens. Don't let my counter cases fool you. It is a rare codebase that doesn't involve some open source software, whether it is merely in the form of a standard library or a widget library, or is full of the stuff. This is by design; if every program had to write every instruction down to the operating system, or the machine itself, there would be no programs. The iterative building process, programs on top of libraries on top of the operating system, is so productive that I can't imagine someone ignoring it. Even for the smallest embedded systems, designers are using the GNU compilers to create great programs for their devices: compile, flash, and go.

2.2.2. Libraries, System Calls, and Widgets

Here we begin to see how open source ideals have changed proprietary development. When proprietary software developers create a program, they may use free software, created or derived libraries, widget libraries, and tools. This includes developers targeting proprietary operating systems such as Windows and OS X. Developers creating software, whether for OS X, Unix/Linux, or Windows, commonly use free tools to do so. They almost always use free libraries in the creation of their programs and often use free user interface elements during the creation of their systems.

Some might think I'm indulging in some mission creep for free software here, assigning a larger role to it than it maybe should enjoy. I'm not. I'll take it even further: if there hadn't been free tools like the GNU compiler collection, the industry would have been forced to create and release them. Otherwise, the computer industry as we know it would not exist and would certainly not be as large as it is right now. This is not to imply that companies somehow owe something to the free software community. However, companies do help out when they can reap a long-term benefit. IBM understands this, as do Novell, Google (my employer), and many others. Even Microsoft uses and releases code under a variety of licenses, including the GPL (its Unix services for Windows) and BSD (Wix), but Microsoft is conflicted both internally and externally, so it's not as easy for it to embrace open source.

Am I saying that without free tools, the compiler would try to charge a per-program fee? No, I think that if free tools hadn't arrived and commoditized the compiler, other competitive concerns would have kept the price of software development tools accessible and cheap. That said, I think free tools played a big part. Free and open source software changed expectations. Microsoft and Intel make no attempts to prevent developers from using their compilers to create free software or software that is counter to their corporate goals. Client licenses, a common fixture in the email/workflow market, are unheard of for mainstream development tools.

If there is one thing about free software that is downright scary to proprietary development shops, it may be this: software that is licensed per client almost always comes under attack from free software. This is forcing in the software industry a shift away from such per-client licenses in all but the most specialized verticalsfor instance, the software that runs an MRI machine, or air traffic control software, both of which are so specialized as to not count, because every client is custom. The grand irony here is that in some industries, such a high cost is attached to developing software that some are forming very open source-looking consortiums to solve common software development problems.