I talk with the press frequently. They thankfully whack down my ramblings into concise quotes. For those who prefer to see more, I try to dump publish slightly polished up conversations I have with press into this new category of posts: Press Pass.
Klint Finley over at ReadWriteWeb asked me a few weeks about “openwashing,” a fancy way of saying “open source software that isn’t really open source enough.” He wrote a nice, brief piece around that topic, “How to Spot Openwashing.”
Here’s the brain-dump I sent him on the topic:
How does openwashing end up happening?
The motivations tend to be one of two things: ignorance of how “open source” should work and look, and/or, profit-motive. There’s another variance we’ll call the “oops, that didn’t work” recovery.
Just not doing it right
Having worked with many companies over the years on going open source (see our report “Going Open Source”), many of them are just not cognizant ahead of time of the missteps that can be made. There’s so much arm-chair lawyering in open source (trade mark, assigning IP, patents, etc.) that it’s easy to overlook or simply not realize how much legal-thinking going open source requires. And if you do something wrong there, then once someone wants to accuse you of not being “real open source,” they can go after that fine print. Of course, as Oracle’s recent trade mark based flap over Hudson shows, those fears can be real: just because you’re not paranoid doesn’t mean they’re not out to get you, as they say.
You can’t buy iPads, let alone food, with “free”
The profit motive is more what vocal folks in this space don’t like. Some would argue that the “open core” model (the software’s foundation, its “core,” are open source but you pay for additional functionality) is open washing (not me), and it can start to paint a picture of open washing models: a company open sources something, but keeps another part closed source, and usually you have to spend money on that closed source to get maximal value out of the open source. This can be just fine, or terrible – it all depends on the communities expectations and how useful the open source software is on it’s own. Clearly, if you’re peddling “cripple-ware” as “open source,” there’s something wrong going on.
Also, in this category are bundlers, or packagers, of open source. A company will take an open source project and wrap it inside a closed source ball. The more intellectually dishonest will try to ape the open source ideas, while the others (BSD and Apple) will completely drop any idea of open, just taking the code. Again, if the overall product is what users and customers want, it’s not really a big deal. Most software that exists today probably includes a lot of open source: commercial software companies would be crazy to skip on the free, high quality software out there and, instead, spend their own time and money to replicate and maintain it.
Another one is to open source a small part of an overall platform, but still keep the important parts closed source. A more common occurrence is to open source a project and then have only people from the original company work on it: the project never allows anyone outside to become part of the project. Here, the “patron” organization wants to motivate involvement and use by open sourcing (saving marketing and partnering pay-off/revenue share budget and energy) but wants to keep control and code. Some could argue that Sun-cum-Oracle’s refusal to grant a TCK license to the ASF is an example of this – as with all examples, there’s lot’s of nuance that makes it a square concept in a round hole.
A sort of “open useless” variant of open core happens frequently too. Lots of IT Management vendors did this is recent years: they’d open source integrations between closed source software and make big fan-fair about doing open source. As software moves more and more to SaaS and cloud, expect to see a lot more of this: the SaaS application is closed, but we’re open source friendly when it comes to integrating with it. You have a sort of “open source as cloud bait” thing going on there. There’s already a lot of hand-wringing over how “open source” companies like Google and Facebook are and what it means for them to open source little bits here and there, but not entire applications. Overall, I’d say people (developers) like it, or at least don’t care so much. Another good example is the very closed world of Apple iOS (whose benchmark for “openness” is, apparently, Microsoft Windows) vs. the more open world of Android.
The other thing you’ll see often here is that a project will be very secretive about what they’re going to work on next. Their road map is not open. It’s always professionally funny when I sit in an NDA briefing with someone working on, ostensibly, an open source project/product and they tell me I can’t talk about future plans. If you open source something, it really should mean more than the source: your community, if you’re lucky enough to have one, wants to know everything, including future directions. The secrecy around Android is a good example here.
“Oops that didn’t work”
The last point is the “oops that didn’t work” effect. Over the past 10+ years, companies have open sourced many things. For whatever reasons, many of these projects don’t work out. Some of them were simply “open dumping” (to use a Marc Fleury term, I believe). Others just weren’t interesting enough to build up a community (remember when there were 5,000 wiki stacks in the mid-2000’s?). And a rare few were simply good enough and didn’t need more work (some SNMP stacks seem to fit in here). Clearly, Nokia thinks that Symbian needs to be less open source.
Another thing you’ll see happen is a company changing the open source licensing to prevent competitors or others from taking revenue from the product. The company may open source some product, find that someone else has commercialized it, and then in freaking out change around the license to prohibit that. This happens more than you might think.
Disclosure: Microsoft is a client, as are many companies using various degrees of “openness” and open source.