Previous    Table of Contents    Up    Next

Open Source within a Company

Everything mentioned so far about running an open-source project or joining an existing one also applies to corporate source, where all of the users and contributors are employees of your company. What changes when everything is done within a company is that the potential audience is much smaller, and depending on the company's culture, it may be more difficult to communicate and work with other participants.

In the normal world of open source, people working on a project come together because of their common interest in the project and generally do not have other connections between them. Sometimes volunteers might be in competing companies and that might influence their working relationship, but by and large everyone acts as individuals, albeit with their own personal technological biases.

Inside a company, however, there can be substantial barriers to cooperation and a tendency to use the official hierarchy of the company to force both how decisions are made and what developers will work on. This is very much at odds with the idea of creating a community-based project. When you are working within your company, there can be lots of pressure to do things the standard company way. In a company-sponsored open-source project, you can fight against this kind of pressure by pointing out the bad press that would ensue, but this tactic does not apply to internal projects.

This highlights the need to have strong executive sponsorship for corporate source projects. Without it, the time employees spend working on corporate source projects will often be questioned by their managers, and in hard times resources for the project will be the first to be cut. This is a typical problem--the work is good for the company as a whole but is not a priority for any specific department. It can take lots of nurturing to get a company's culture to embrace the cross-company cooperation needed for corporate source to be successful.

To justify a corporate source project, it helps to be able to point to successes within the company due to using the tools developed by the project. The crudest way to do this is just to measure how many times the tools have been downloaded. That gives some measure of interest in the project and can be useful for potential users--it highlights what others have found useful in the past. Another measure is to look at the number of people contributing to the project and the parts of the company they are in.

The normal wisdom is to try to minimize any barriers between an open-source project and a potential user. So we advise not requiring users to register in order to download. However, for their corporate source effort HP does require employees to register in order to download a tool. This, then, provides information on where in the company a tool is being used and enables HP to follow-up to see how it is being used. Part of the follow-up is an email message to the author or authors of the tool. This provides the authors with evidence of the use of their contributions, which can be used during performance reviews; it also provides an incentive for the authors to contribute more by improving the tool or contributing others. Thus, in this case, what would otherwise be a barrier is actually an enabler.

One of the major problems faced by efforts to encourage software reuse is making developers aware of existing code. Likewise, for corporate source, if customer engineers do not know that there's a great tool that a corporate source project has developed, they will never use it. It is vital to make sure that when good tools are developed that this be advertised across the company to all those employees who might benefit from it. This requires communication between parts of the company that traditionally do not interact much. It also calls for communication at the grassroots level rather than through the normal organizational channels. Messages from executive sponsors can help to make the corporate source projects more visible.

At HP Labs, the code repository was handed over to the corporate librarian, who organized it for easier search and retrieval. This constant attention to the contents of the repository for the purpose of making it easier to retrieve made a significant difference in the use and usefulness of the repository.

This is part of a common thread for the use of open source. The source code is produced by developers, who have, in general, the mindset of an engineer. Engineers are good at looking at a complex situation, understanding it, and then either repairing it or designing something that helps make it better. That is, they are good at puzzling things out. For many engineers working on an open-source project, once the code is done, everything is done. Perhaps this attitude comes from the belief that other people are like engineers and that therefore anyone should be able to figure out the rest. For example, engineers are sometimes poor writers because they believe that once the sentences are more or less on the page, the meaning can be puzzled out.

Therefore, we recommend that, for the documentation, the website, building the community, organizing meetings, and anything else that is not engineering the source code, you find people who are good at those things and who value them. The developers will appreciate it--perhaps without knowing why.