Corporate Open Source Considerations.

Continuing the thoughts from my previous post on OpenWashing…
If openness is so good, why don’t tech companies simply share all their software code?  Open Source is “a good thing” so why not opensource it all — going whole-hog?  I get asked this question every so often.  Funny, since I also get asked “Why would a company give anything away for free?”  What a polemic world!  So let’s talk about the grey in between and some of the things that goes into the decisions.

What do companies think about when they consider their public Open Source activities?  Let’s first remember of the relevant motivators:

• From a commercial perspective, companies seek to make money.  i.e. to spend less or make more.   Corporate Open Source strategies are not about altruism per se, but about achieving business goals.   Altruism may play into this nicely, but remember, a company has a responsibility to its shareholders to be a company.  And indeed, there are ways to both, make money and spend less, via Open Source.
• From a marketing perspective, companies want to be loved and admired for the good they do. There’s a bit of vanity about it, but there’s also a path to better market share and profit (see the point above).  And in environments where there is a talent war, the marketing angle leads nicely to the next point — which has to do with the recruitment and retention perspective.
• Companies want to attract talent and retain them — and they know that many engineers in the tech world strongly value working on Open Source code. Why?
  • It appeals to their values about software freedom and the virtues of openness.
  • By contributing to Open Source, they can improve their personal brand in the tech community.
  • By mastering popular Open Source technology, they improve their marketable skills, useful for landing their next job.

And thus, there are motivators for companies to participate in the act of publishing code as Open Source.  Their developers want it, it’s good for the brand, and there are ways to connect this act to saving money, is some cases, making money too.  Tech companies looking for good engineers will want to promote their “openness” — but should be aware that the door swings both ways.  Openness will attract developers, and will also enable them to leave with ease.

There some of the risks involved in publishing Open Source that you might consider.  Some are more obscure, but do come up — and  I see some of these examples nearly every day, including:

1. Revealing information that you did not want to reveal — e.g.:
   • A proprietary algorithm that differentiates you from your competitor.  You might even have a software patent on it (if your company registers patents).
   • A future product or plan that might be embedded in some code comment block.  Sometimes you find juicy things in code comments, things you want to clean up before you publish the code.
   • A security vulnerability that you worked around that reveals a poor security practice that you do, but cannot avoid doing for some reason.
2. Agreeing to some license term that hurts you — e.g.
   • Signing a contributor license that does something you did not want it to do regarding your copyright or patent rights.  (See my post “Why read the contract.”)  Some of these licenses are less nice than the people who ask you to sign them.
   • Using a restrictive Open Source license that hinders  some future business plans to invest or divest in part of your business.  (Open Source reviews are part of some technology M&A deals and can impact the value of a business deal.)
3. Commoditizing a product of yours by giving something away that erodes your market opportunity.   Examples abound of companies who hurt their own products by supporting an Open Source alternative.  Classic one from many years ago is IBM’s support of the Eclipse development environment hurting sales of their WSAD product.
4. Creating ill will between you and a business partner.  I’m not going to get into details, but there are cases where you might be OK with opensourcing, but then realize that it would really be perceived negatively by an important partner based on some other deal you have in the works.
5. Dealing with code where the ownership is murky.  Unfortunately some developers take code from their previous employer and bring it to their next job without permission. Sometimes it’s not clear who owns the resulting code, since code is a pretty dynamic thing — an active project sees code changes every day.  It’s not always easy to get to a clean version of the code you do or don’t own.  You can’t opensource code that you don’t own — so you have to get to a clean state first.

As much as there is motivation to publish Open Source, there are issue that might de-motivate this activity.  Hence the “whole-hog” approach does not make sense.  You have to consider a couple of  stakeholders and their issues first.  And then you can make the call about opensourcing.

Once you decide that code should be opensourced, you need to consider other issues too — for example, which is the appropriate license to use, and should your project be managed by a foundation or run on it’s own (within something like GitHub or Sourceforge — or one of the other well-run forges).  There are important decisions to make here too.

One thing I admit:  I am suspicious of people who give me a quick response, with emphatic and passionate overtones about the “only true way” to do Open Source.  Personally, I see a variety of options, each presenting different advantages.  Some options are more attractive than others.  Some options seem better for some types of code than others.  Some options are better for the companies sponsoring the code, others for the developers using the code.  And thus you have to make thoughtful considerations.  You also have to take some calculated risks.  Open is usually good, but it’s very hard to reverse.

Hey, all in a day’s work.

Share/Save

Tagged as: balance, behaviors, considerations, motivations, Open Source, rewards, risks