Open Source and Corporations - Can't We All Just Get Along?


Corporations and the Open Source community seem to have a love/hate relationship most of the time, and I think it stems from several key misunderstandings (mainly on the part of the companies). A lot of companies (though there are notable exceptions, such as IBM) seem to look at Open Source as a source of free (as in beer, not as in speech) code/labor. In other words, management sees that code and those developers as a great way to shortcut the product development process, do it for less, and then 'profit ensues'.

I know that sounds funny to a lot of technology people (like me) who are familiar with and involved in the Open Source community, but that mentality is very real in larger/older companies (especially those in consumer electronics sectors). It doesn't help that marketing and PR grab ahold of the notion of Open Source as a great 'hook' to make their company or product offering sound sexy and appealing. The unfortunate reality is that a lot of corporate execs consider Open Source to be a 'risk management exercise' (yes, I actually had an executive that I met one time tell me this).

Now, lest anyone think I'm picking solely on the corporate guys, the Open Source community is complicit in this as well. In larger projects inhabited by ideological zealots that believe Open Source/Free Software is the end-all/be-all (think Richard Stallman), the blinders get put on when it comes to the reality that businesses are in business to make money. Making money is not a bad thing, but the notion that all code should be free and open flies in the face of that for these people, causing them to spend lots of time, effort, and money chasing down every single last license violation that they can. I prefer to recognize the needs of both the corporations and the individuals and find a way for both of them to satisfy the WII FM (What's In It For Me) notion.

Now, let me be clear - I don't think Open Source license violations should be tolerated, but I'd like to see a lot more emphasis on finding 'win-win' situations between corporations and the community. The reduction in legal expenses alone should be incentive enough for both sides to try and come to amicable solutions. Below are some "Do's and Dont's" that I hope will give both sides some ideas on how to accomplish this:

Companies:

DO have a plan to work with Open Source communities - don't grab the code, fork it, and then go along your merry way. It costs you more money in the long run (for bug fixes and maintenance), and you lose at least 50% of the value of working with Open Source in the first place. Remember that 'compliance' and 'risk management' are only half of the plan - community interaction is at least as important.

DO participate actively in the community, whether it is mailing lists, forums, or other forms of communication. Make your voice heard, but remember you are but one voice in the community, and you are rarely the driving factor in decisions.

DO utilize Open Source in a way that you can treat it as a commodity - use your engineering resources on more value-added projects, since it is likely you will not be able to keep up with the amount of code that a good community project can produce.

DO re-evaluate if you truly have critical 'intellectual property' in a piece of code. If you don't, and the community is willing to extend/support that code, consider putting it out with an appropriate license to let them do so.

DON'T slight the community, and do your part for the project (if you find a bug, and determine it isn't fixed, offer to fix it and contribute the patch back).

DO try to keep up to date with the latest code revisions (both for your own regression testing and to allow you to contribute back fixes easily).

DON'T try to make up your own 'Open Source' licenses by attempting to modify an existing Open Source license for your purposes - the community will reject it out of hand, and your credibility will be zero.

DO remember that, except in certain circumstances, these developers do not work for you - plan your release cycles and development processes to take into account the variability of the community you are working with.

Open Source Community:

DO have patience with companies as they work through a ton of internal issues related to being better open source citizens.

DON'T immediately call out the attack dogs for perceived license violations - attempt to work with the company.

DO understand if companies choose to architect things in a way to avoid having to give up intellectual property through "license taint". See comment above about 'making money'.

I believe we need to get to a place where both the Open Source community and the corporate world work together consistently for the greater good of software. It is a difficult challenge, but one well worth expending the effort for.

Comments

Post a Comment

Popular posts from this blog

Great Panel Discussion!

Thanks to Gwyn Firth Murray , Larry Augustin , and Jeff Luczcz for a very entertaining panel discussion around Open Source at the recent eBig meeting . I was a bit nervous about how this panel would come together since I was the 'rookie,' whereas Gwyn had worked with Larry and Jeff separately before. However, the commonality of the passion for Open Source brought this panel together nicely and there was an excellent exchange of ideas between and amongst the panel (as well as our audience). I think we had someone in the audience comment on the fact that it seemed like we had all known each other a long time! :) The areas we covered during the talk were: licensing, community development, and reasons for using Open Source. I think the panel all agreed on good reasons for using Open Source, with all of us giving cogent examples of what the value proposition for using Open Source is (taking advantage of the huge amount of R&D and work that goes into good Open Source project
Read more

Community Management is a Career, Not a Job

'Community Management' is a hot topic, & a hot job field , but I think it's important to articulate that it's not a role which should be approached as a 'job'. What do I mean by that? Community Management should NOT be: A role you 'settle' for because you can't do other things Something you do as an ancillary part of your 'real job' Something you get into 'because it's hot right now' A position that you can perform in isolation, without constant upgrading of your skills/knowledge I've talked in the past about what kinds of skill sets I believe are necessary to be an effective community manager, and as I thought about my own career path, I realized that early on in my community management career, I considered myself an engineer doing community management, whereas I now think of myself as a community manager with an engineering background. It is a subtle, yet hugely important difference - one that allows me to draw on a
Read more

The Power of the Open Source Periphery

Like a lot of people in the tech world, I try to read a variety of publications (both online and physical versions) to keep up with what is going on in the dizzying world of technology. Recently, I read a great article in a recent issue of Wired entitled Accept Defeat: The Neuroscience of Screwing Up . This article explains in some detail, with examples, the problem of 'failure blindness' in scientific research. This phenomenon causes scientists and researchers to ignore anomalies in their results they didn't expect, which are therefore categorized as 'failures'. The article goes on to state that one of the best ways of overcoming this bias is to involve other people from outside of your immediate speciality in discussions about your results. For me, this triggered the thought process of why it's important to encourage participation in your communities (Open Source or internal) from folks on the periphery of your project - non-specialists who have somethin
Read more