Novell and Microsoft have been spending the last few days releasing dueling statements concerning the implications of their recent agreement. Novell insists that Linux doesn’t infringe any Microsoft patents, and that their patent agreement with Microsoft shouldn’t be interpreted as an admission to the contrary. Which raises the question of why you’d pay $40 million for superfluous protection. Microsoft says that they “have agreed to disagree” on the subject.
It’s not clear where this is going to end up, but one thing that’s absolutely clear is that this has become a PR nightmare for Novell. A lot of people in the Linux community seem to feel betrayed by Novell’s behavior. The agreement has already done damage that will take months for Novell to repair.
Braden asked on Monday how “a boycott would materially hurt Novell.” Below the fold, I’ll see if I can elaborate a bit more on why I think the open source community has so much leverage in this sort of situation.
It’s important to start with why a commercial company would contribute to an open source product in the first place. The largest software companies in the world mostly make their money by selling proprietary software, which has the obvious advantage that they can charge money for the finished product. Yet more and more successful companies–IBM, Sun, Red Hat, Oracle–have embraced Linux.
The fundamental reason is that it saves them a lot of money. Developing an operating system is an extremely complex and difficult undertaking. To do it all in-house, as Microsoft does, costs billions of dollars. So if you can get other people to do most of the work, that’s a huge cost savings.
The problem, obviously, is how you make money from a free product. Most companies do it by selling relationships. When you sign up as a Red Hat or SuSe customer, you’re not paying for the software itself (which you can get for free) but for a relationship with the company that developed the software. That relationship is valuable because the people who created the software are likely to be the best at offering support services–fixing bugs, adding features, customizing it for different uses, etc.
Of course, you could hire somebody else to study the software and provide those services without interfacing with the broader community. That seems to be Oracle’s strategy. But this misses the point that an open source company doesn’t only sell a relationship with its own programmers. It also indirectly sells those programmers’ relationships with their peers outside of the company. A few examples:
- Incorporating patches: One of the services that an open source company can offer is customizing a popular open source product to meet the needs of a particular client. A client might have a particular feature that he desperately needs to be added, or a particular device that he desperately needs supported. He can hire a company like Novell to assign one of its programmers to do the programming necessary to meet the client’s needs. Now, when the programmer is finished, he will share the code with the client. But he will also submit a patch to the maintainer of the software in question to allow the feature to be incorporated into the main product.
This isn’t just an act of charity on the programmer’s part, nor is it solely to comply with the GPL. The more important reason is that as the software continues to evolve, the programmer wants to ensure that his feature continues to be incorporated into future versions. If he didn’t submit the patch, then he’d have to go back and re-implement the feature every time a new version of the software is released. If a company stopped submitting patches, over time the differences between its internal version of the software and the official version will get larger and larger, until keeping them synchronized becomes more work than it’s worth.
Hence, if project maintaners were to stop accepting patches from Novell, it would have a serious detrimental impact on Novell in the long run, as more and more of the software-maintenance work would shift from the community onto Novell’s own programmers.
- Bug fixes: Another service that an open source company can offer is help convincing outside developers to work on their clients’ problems. If I’m a Novell programmer and a big Novell client comes to me seeking to fix a particular bug, I might fix the code myself. But it’s much easier to fix code you already know well than to deal with code you’ve never seen before in your life. So if no one inside of Novell was working on the particular software the client needed fixed, I might go to someone who was working on that code and ask, pretty please, if she could move this particular bug up on the to-do list.
Now, that person might be an employee of another company like IBM or Red Hat, or she might be a volunteer, such as a grad student or a programmer who works on open source in his free time. Either way, she is far more likely to help me out if we’ve got a good working relationship. Even if she works for a competitor, she might still do me a favor in the expectation that I’ll reciprocate next time one of her customers have a problem that one of my colleagues can help with.
- Product Roadmap: Another thing that a company can offer its clients is information about and influence over the future development of a project. Up-to-date information about when new feature are likely to be added to a product can be extremely valuable to a company trying to manage a large network. Even more valuable is the ability to effect that roadmap: to be able to push the project in a direction favored by a client. This sort of information and influence is only available to people who are actively involved in product management: who are immersed in the mailing lists and IRC conversations in which such decisions are often made. If all of the hundreds of open source projects whose work goes into SuSe stopped cooperating with Novell, the company would find itself at a serious competitive disadvantage, because competitors like Red Hat and IBM would be able to provide their customers with much more complete and comprehensive information.
- People: A big cost of being ostracized would be the risk that they’d run the risk of losing their best programmers to other open source shops. For all the reasons I mentioned above, the most prolific open source programmers, such as Linus Torvalds and Alan Cox, have no shortage of job opportunities. They are likely to be strongly motivated by the desire to work for an organization they can be proud of, and to earn the respect and admiration of their peers. Given that they already tend to be quite well-paid, larger paychecks aren’t likely to be a good motivator. So I wouldn’t be surprised if some of Novell’s most talented Linux programmers are polishing their resumes and looking around for new jobs.
This isn’t actually all that different from most professional jobs. One of the things that make me valuable to the Show-Me Institute is that I have friends and former colleagues who work at a variety of other public policy organizations. That means that if I need to ask for a favor from another organization (say, I want someone to collaborate on a joint op-ed), I’ll know exactly who to ask, and that person will feel favorably disposed to help me out. Most white-collar employees are selling their employers a network of connections alongside their concrete skills. This is more pronounced for open source developers, but the principle is the same.
So what makes software valuable isn’t just the source code, but the web of relationships and knowledge that produced it. This is obscured with a lot of consumer software because what you’re officially buying is a shrink-wrapped package with a CD in it. But even there it’s clear that you’re buying more than a CD. You get technical support, an assurance that the software will work with your hardware, bug-fixes and upgrades, etc. This is even more true of the type of software larger companies buy: a large company would never buy a copy of Oracle without a support contract. Much of the value lies in the relationship with Oracle, not just the 1s and 0s on the CD.
The same principle applies to open source software. The only difference is that because the code is given away for free, the network of relationships and knowledge that produced it is where all of the money-making opportunities lie. The vast majority of that network is outside of any one firm, so cutting yourself off from the broader community means cutting yourself off from much of the value you can offer to clients. That’s a recipe for disaster.
The Technology Liberation Front is the tech policy blog dedicated to keeping politicians' hands off the 'net and everything else related to technology.
Comments on this entry are closed.