Section 2.6. How Proprietary Software Development Has Changed Open Source

2.6. How Proprietary Software Development Has Changed Open Source

Open source isn't magic, and developers aren't magicians. No developer is immune to security problems and bugs creeping into his code.

2.6.1. Bugs/Security

Free, open, proprietary, closed....Bugs happen. I think open source means fewer bugs, and people have written tens of thousands of words explaining how they agree or disagree with me. One thing I know I'm right about is that both kinds of code have bugs. Bugs persist longer in closed codebases, and their closed nature keeps bugs persistent.

If I may paraphrase Socrates, "An unexamined codebase is dead," and by dead I mean killed by the hostile environment that is viruses, worms, crackers, and Trojans. Like bugs, security flaws happen in both free and closed software. As a project matures, it must assemble a mantle of testing and quality assurance (QA) techniques that are vital to its ongoing health. I think open source development has learned much from the processes that proprietary software development houses have come up with to support their paying customers.

2.6.2. Testing and QA

As projects mature, so do the testing suites around them. This is a truism for free and for closed software codebases, but the research around this originated in commercial software/hardware and in academia, and open source software has been a ready consumer of this information. The most popular talk I attended lately was in unit testing for Python at the O'Reilly Open Source Conference. The room was packed, with people sitting in the aisles. Testing is huge and is required for any project, free or not.

2.6.3. Project Scaling

Scaling is hard. Whether we're talking about development group size, bandwidth, space, or whatever, scaling any programming project is nontrivial.

Software development has its limits. Product teams can't grow too fast or too large without one of two things happeningeither disintermediating technology or project ossification. Fred Brooks's seminal book, The Mythical Man-Month, covered this in depth, and the existence of F/OSS development methodologies doesn't change that. In fact, the tools and changes free software has brought to prominence are all around disintermediation and disconnected collaboration.

F/OSS isn't magic. It isn't breaking the speed of light. Most projects, with some notable exceptions, are composed of small teams, with one to three people doing the vast majority of the coding. If you care about project size, you would be well served by reading the findings of the Boston Consulting Group's study of open source software developers on SourceForge. This revealing study analyzes project metrics and motivations. For one thing, you see that projects almost always comprise fewer than five active developers. Many projects have only one developer.

So, what am I talking about when I say disintermediating technology? Look at it this way. Imagine that one person decides to create a cake from scratch. He'd have to start with a cake mix and some milk and an egg, right? No! He'd need chocolate, milk, flour, yeast, water, and the other ingredients, right? No! Just for the milk, he'd need a cow, some food and water for the cow, a bench, a milk bottle, a chiller, a pasteurizer, a cap and a rag, some bag balm, and so on, right? Well, you're getting closer. The point is that we accept interfaces all the time, and the successful project finds these interfaces, formalizes them, and spreads the work out along these lines.

We accept power at 120 volts at 60 hertz alternating current. We don't generate the power ourselves. We accept that we don't need to dig for oil, refine it, and pour the refined gas into our cars. We use interfaces with different systems all the time. Programs, too, have interfaces, and the success of a program is in how it manages these interfaces.

Proprietary or not, a successful program is one that interfaces effectively between systems and teams working on these systems. Microsoft doesn't have 5,000 engineers working on Windows. It has them working on the kernel, the printing subsystem, the windowing system, the voice synthesis module, and other components. More importantly, it has groups that work on interfacing between the systems so that they (theoretically) work as a whole. Likewise for the Linux kernel; Linus interacts with a number of captains who control different subsystems, including networking, disk drives, memory, CPU support, and so on. Fractionation, when possible, is key, and when not possible, disastrouswhich is why groups working to integrate the whole and making sure the interfaces are appropriate can make all the difference in the success or failure of a project.

This interface management is something that free software has done very well. Many commercial developers would be well served to learn from open source's interface management practices.

2.6.4. Control

Control is something customers and end users have never had over their code. You don't buy proprietary software, you rent it, and that rental can be rescinded at any time. If you read the end-user license agreements (EULAs) that accompany proprietary software, you may be left with the feeling that you are not trusted and not liked all that much. For instance, in Microsoft Word's EULA, there is this charming note:

You may not copy or post any templates available through Internet-based services on any network computer or broadcast it in any media.

So, if you were to take a standard Microsoft Word template (which all templates are derived from) and make one that is suited to your business as, say, a publisher, you would be in violation of your EULA with Microsoft, and thus vulnerable to its lawfirm.

Controlling your software destiny is something I consider extremely important. Take, for instance, my employer, Google. We are able to fix and change the Linux kernel to fit our very specific needs. Do we have to check with Linus or one of his lieutenants before, during, or after we change the network stack? No. If we were running NT on our machines, we would be unable to get such changes made, and were we to enter into a deal where Microsoft would incorporate our requested changes, we would in effect be informing a competitor of our development strategy.

Another example is a recent service pack from Microsoft, which featured a firewall and antivirus package. This package, which is turned on by default after service pack installation, was aimed at stopping the viruses and Trojans endemic to the Windows experience. Funnily enough, it considered iTunes a virus and presented a fairly confusing message asking the user to authorize the program's use of the network.^[9] That Microsoft's own media player, which has common network access methods, wasn't impeded is telling.

^[9] iTunes has a nifty sharing mechanism whereby users stream music to other iTunes users over the network. It's pretty neat.

Your computer is not your own; you only borrow that which makes it useful, and when that is taken away, you are left with nothing but a toxic pile of heavy metals and aluminum.

I think this is a subtle but important part of open source's popularity. Many people and companies are interested in controlling their own destiny, and Linux and other open source programs make this possible.

2.6.5. Intellectual Property

Free-software developers believe in intellectual property, probably more so than people who never consider open source software. Developers creating open source have to believe, as the entire structure of the GPL, BSD, MPL, and other licenses depends on the existence of copyright to enforce the clever requirements of those licenses.

When you hear people criticizing free-software developers as guiltless communists or pie-in-the-sky dreamers, it is worth remembering that without copyright, there can't be free software.

Discussions concerning intellectual property and free software usually revolve around two issues: patents and trademark. Software can be patented, and things can be trademarked. Exactly how these intersect with free software is complex. Can a piece of software which is patented be released under the GPL and still hold to the letter of the license? Can a program name be trademarked and then released under the BSD and still be a meaningful release? Legal opinion and precedence thus far provide no definite answer.

Open source developers are learning, though, paying attention to the current events around intellectual property and how it affects them.

The reality of intellectual property is something modern developers are almost required to learn. Learning the laws concerning software is the way to protect themselves from those who might send the feds out to arrest them when they come to the United States. I know that sounds like I'm typing this with tinfoil on my head, but I am not kidding.^[10]

^[10] I wish I were, but I'm not. It happened to Russian developer Dmitry Sklyarov, who intended to discuss his reverse engineering of the Adobe PDF file format at the DefCon developers conference in Las Vegas. Upon landing at McCarran International Airport, he was met by the FBI, which placed him under arrest under the auspices of the Digital Millenium Copyright Act on behalf of Adobe Corporation. As a result, Linux kernel developers no longer have a substantial meeting in the United States, choosing instead to meet in Canada and Australia, two countries that do not have similar laws and rarely extradite for intellectual property-related crimes of this nature. Developers felt this was necessary because the Linux kernel uses code that was reverse engineered. Reverse engineering, by the way, is what made Dell, Phoenix, AMI, AMD, EMC, and a large number of other companies both possible and profitable.

The problem with this learning process is that it does take time away from coding, which is not good and is a net loss for free softwarewhich may indeed have been the whole point.