Previous    Table of Contents    Up    Next

Tension between an Open-Source Project and the Rest of Your Company

The Blackdown incident highlights another mistake: Sun failed to publicize participation by Sun engineers in the Blackdown work and other open-source projects. If people inside of Sun had known about this, then the press-release mistake would never have happened. Moreover, many in the open-source community are unaware of Sun's many contributions to open-source projects, which causes Sun to not receive the credit it has earned. According to the Orbiten Free Software Survey1 done in May 2000, Sun was in fact ranked as the second largest contributor of code to open-source projects. Your company needs to let others know about its contributions to open-source projects to get the credit it deserves--but without overemphasizing or hyping its participation.

It's not enough that everyone working on your open-source project interact appropriately with the outside world, you also have to deal with the rest of your company. If others inside your company do not understand why you are using open source and the implications of that for their work, then your project can run into major trouble. Open-source projects need different resources than proprietary ones and have different constraints on how they operate. If this is not understood by those outside your project, then they likely will work against you in the normal internal politics that go on inside every company.

One mistake your open-source project can make is to fail to market itself within your company. Moreover, your message needs to have a different emphasis from the one used for people outside of your company. You need to communicate how the goals of your project help further your company's business goals. If you fail to do this, then your project may be seen as irrelevant and other, proprietary efforts will be given precedence. This marketing must be an ongoing activity, especially when there are changes in upper management.

You must educate people at your company about what metrics will be used to measure the success of your project. These are likely to be quite different from the more familiar metrics used for proprietary projects. Anyone opposed to your project, for whatever reason, will have a much harder time proving it a failure if everyone understands the appropriate metrics for measuring it.

The results of a lack of internal marketing and poor metrics can be devastating to your project if your company hits hard times and needs to look for people to lay off. This happened at Sun in 2001 when the size of the Jini development team was reduced. Particularly hard hit were those folks working on community issues, including the main community manager (who was also one of the original developers of Jini) and the person working on updating the Jini.org website. These were very visible cuts, and the community began to conclude that they signalled that Sun was pulling back from Jini technology. It took several messages from Sun executives to reassure the community that Jini was still important to the company.

A common management mistake we have seen is to have people trying to serve two masters. Developers helping to grow the community while writing code to meet internal deadlines for proprietary work will feel pressure from the company to make the proprietary work higher priority. It is necessary to separate developers into those focused on the open-source activities of the project and those doing work on proprietary projects. Otherwise, local pressure from managers and coworkers will ensure that the proprietary aspects are given priority. A failure to include community-related metrics in the performance reviews of those involved with open-source activities is a common mistake, with the direct result that those community activities tend to be neglected.

The worst type of mistake that projects make is to try to cheat or put something over on their communities. This could be as minor as sneaking code into the code base or as major as blocking a competing company from checking in code it needs. Any actions that treat the open-source project as if it were a proprietary effort owned by your company destroys the community's trust in your company--both for your project and also for any other open-source projects that your company is involved in. People who think that they can get good PR for an open-source project while playing the same old proprietary game are sadly mistaken. If someone tries to avoid, ignore, or otherwise fool your project's community, you need to point out that your company has made a public commitment to your open-source community and any monkey business will get your company bad publicity. Any activity that does not show respect to the community and the approved community processes should be avoided, even when apparently done with good intentions.

Tension between the proprietary side of your company and your open-source project is apt to arise over your project's schedule. Groups doing proprietary efforts within your company expect you to have control over when your project does a release and what features are included in it. If their products depend on yours, this may cause them to make unrealistic plans. You need to educate them so that they understand that your community has a major say in the release process.