Debating Open Source Software Definitions
Update [2-Mar-2007, 14:06}: Stephen O'Grady's great commentary is here. (Admittedly, he's agreeing with me.) Here's another way to think about the debate, and my contention that it's orthogonal. If we were to try and name opposite ends of a spectrum, and I was to say "open", you'd probably say "closed". If I said "free", you could say "encumbered". As long as you place "commercial" on the other end of "open", you are:
- Allowing Microsoft PR to frame your market discussion. It's their Shared Source framing afterall.
- If you're in business, you're blinding yourself to all the other opportunities, tools, and processes you can use to best engage with customers. It's wearing similar blinders to when using the "stack" metaphor instead of realizing the "network" metaphor.
It all started when a terrible article ("Ten Leading Open Source Innovators") prompted Nat Torkington to ask "Is 'Open Source' Now Completely Meaningless?" (The article also provoked Chris DiBona's ire). Enterprise Open Source Magazine jumped into the fray with an odd article grabbing sound bites from various people and going under the sensational headline "How Open Is 'Open'? – Industry Luminaries Join the Debate". Michael Tiemann chimed in with an articulate response, Nat finished up a roll-up post, and it even provoked r0ml to blog again -- always a good thing.
So what's all the fuss about?
This debate actually started for me several weeks ago with a colleague at Microsoft when we got into the debate (yet again) over "commercial software versus open source software." And herein lies the rub. These concepts are orthogonal.
Here's how I try to explain things to customers so they don't get all caught up in these tempestuous confusing debates and stick to buying the same damned things they always bought because they understand the old.
First, software projects are interesting buckets of technology. These projects have users and contributors, i.e. a community. Open source has a definition. So does free software. If these projects are open source or free software, then they meet one (or both) of these definitions. Pretty simple really.
Second, products are packaged, installable, tested, documented, supported, and maintained for customers. Companies build products as part of their value proposition to their customers. Another way to say this is that customers buy solutions, not software. Still pretty simple.
These two paragraphs are orthogonal.
I am not suggesting that a project's community does not build packages, test, document, support, or maintain their project software, BUT once a commercial transaction between a customer and an organization takes place, the customer's expectation needs to be met. It requires a customer and a company and money to change hands.
Until the buyer puts their money where there mouth is, they're not a customer. For an open source project, they're simply a user. Contrast customers with community (users and contributors). Love them both. Respect each of them for what they bring to your company. Do not mistake one for the other. [Insert my favourite Mårten Mickos quote here.]
Companies can use free and open source software as part of their solution. To "build" versus "buy" in their product development processes, they can now add "borrow" and "share". A company can use collaborative development as a community engagement technique. Instead of traditional push selling they can hopefully develop a large user community (which has tremendous value in its own right) that they can then turn into customers. It is a set of techniques (tactical or strategic depending upon the company's use). Nothing more; nothing less. Mike Olson is right -- there is no "open source business model".
Customers care that they're buying "open source" and "free (Libre!) software" or that your product is "disruptive to the incumbent" as much as they care about how many patents you filed, the language you wrote the software in, or your accounting practices. They do care that you provide value for money, and that the solution meets their needs. Their needs may even include source access, but since most "open source" companies get concerned when customers touch the code themselves, crying support fouls and warranty violations, it would seem the "customer" really needs to be a project "user" for such things to work to meet their needs.
Some customers may participate (as user or contributor) in your community or the communities in which you too participate (as user or contributor). This is a great customer engagement mechanism, hopefully developing trust, demonstrating expertise, and exchanging ideas. It's as important as the rest of your customer service practices. It may even be a better way to have conversations with customers (current and potential), than old style sales and marketing techniques.
So does this mean we're now going to need to debate and define whether they're an "open source customer"? Or a "free software user"? Will that debate center on how much they use? Or buy? Or contribute? Or whether they also bought and use closed source products? What if they paid a consulting services organization to build a solution, and contributed some of it to an open source project?
Tempest, meet Teapot. Teapot, Tempest.