Before you can announce your open-source project to the world, you have one last hurdle to clear: getting official approval from your company. Working with open source is similar to introducing a new product or making use of another company's proprietary code. In both cases, your company is making a legal agreement that can limit future choices and create future obligations. This is all part of normal business and so your company should have an established procedure for approving the use of open source in company activities. Just as most companies require approval before a new product is introduced or an old product is retired, there should be an official approval process to create a new open-source project or end participation in an existing one.
A small company might do this casually, whereas a larger company will probably have a formal approval process. If you've done all of the steps mentioned so far in this chapter, then you should have answers to the questions that will be asked during the approval process, and you should have no trouble getting your project approved.
Most companies will have different approval procedures depending on whether a project is intended to create a new open-source project to release source code developed internally (outbound open source) or whether code from an existing open-source project will be used in-house or incorporated into one of the company's products (inbound open source). There may be still a third process to approve joining an existing open-source project, where you plan to both contribute company-developed source code and make use of externally developed code.
Your company should also have an approval process for employees who are working on an open-source project as individuals on their own time. Although this is primarily to protect that individual and the open-source project they are participating in, it can also benefit your company by signalling its support for open source.
Finally, there needs to be an approval process for stopping work on an open-source project or decreasing the company resources allocated to it. Just as every company needs to control how it ends the life of a product, similar end-of-life (EOL) considerations apply to stopping work on an open-source project.
Different issues and concerns are important for each of these situations; we discuss each in turn. Note that each company will have its own process, so you need to contact your company's legal department for details of your company's policy.
Because of the possibly serious implications and requirements associated with both inbound and outbound open source, it is important that any approval body consist of executives at the same level as those who approve new products. The approval board should include senior executives from development, marketing, product planning, and legal. The reviewing team may include the head of your business unit.
It is vital that the approval of a company-sponsored open-source project come from a level higher than that of the manager who will be running the project, and it should come from a level above all of the groups that will be affected by the project.
If you are creating a new approval process for your company, be sure to announce it to everyone who might be involved. Especially when it comes to downloading source code from the Internet, many engineers may not realize that they are potentially exposing the company to harm.
Creating a new open-source project is almost like releasing a new product--it consumes company resources, its quality reflects on your company, and it implies a certain commitment. If you start a new project and it fails, this will probably generate bad publicity for and bad will toward your company. The approval process needs to weed out the badly conceived projects and make sure that proposed projects have not neglected anything important.
There are two parts to a basic approval process for creating a new open-source project: a business analysis to explain your business strategy and make the case for doing open source and due diligence to guarantee that the source code does not include any embarrassing comments or third-party encumbrances. Only after both steps have been successfully completed can the project be started. In fact, no announcement of your company's intent to release the code should be made until both steps have been completed.
Due diligence includes a review of the source code and documentation by your company's legal and technical staff to determine whether any third-party technology or proprietary information has been incorporated into the source code you are planning to release. This is done by examining the source code thoroughly to determine the origin of each part. Any code not developed by your company must be checked to determine whether it is under a license that allows you to include it in a public release, and, if not, the code must be replaced or relicensed.
Upon successful completion of the due diligence process, the approval board that reviewed the business analysis should either approve the project itself or pass a recommendation to an appropriate senior executive for final approval. Once the project has been approved, you may announce the project and release the source code.
If you are planning on downloading source code that has been released under an open-source license, then before you can incorporate that code into a company product or use it internally you will first need to get company approval. This is to ensure that your business unit, any affected functional groups (for example, support), and your upper management are making informed decisions when they acknowledge and accept the risks and obligations dictated by the license that the downloaded code uses.
The approval process needs to review the business case for using the downloaded code, including how these risks will be minimized or handled. Issues that must be addressed fall into three main categories: business analysis, strategic analysis, and legal review.
Check with your company's support division that the appropriate support and engineering resources are available to support the downloaded source code once it has been embedded in one of your company's products.
Once you have the information required by these steps, the approval board can review matters. Only after approval is granted can the downloaded source code be incorporated into a company product. Once it has, your group will be responsible for making sure that your company complies with any requirements imposed by the download license.
Several groups in a company might want to use a specific downloaded technology--especially one used only internally and not in any company products, such as Emacs, Apache, or Tomcat. For these cases, it might make sense to create a fast-track approval process that can be used to quickly approve requests to use downloaded software that has already been fully reviewed. The only thing that needs to be checked is that the software will be used the same way.
It may also be possible to automatically approve software downloaded for an employee's individual use, such as a calendar manager, address book, news reader, or web browser. The key point here is that the employee is not modifying or redistributing the software. But even in these cases it is important to check that the license used by the software does not preclude its commercial use, the use of the software as part of an individual's job.
If you are planning on having your company's employees participate in an existing open-source project, then before they can do any work with it you need to get the proper approval. This approval process will probably be similar to that for participating in a joint effort with another company or an industry consortium. In some cases, all that may be required is that the direct managers give their approval to the participating engineers. For example, a small, focused effort by one of your engineers to help an open-source project adapt its code to run well with one of your company's products should not require a heavyweight approval process.
If code previously developed by your company will be contributed to the project or if the code developed by the project will be incorporated into one of your company's products, then one, or both, of the previous policies may apply and require an additional approval process.
Many software engineers choose to spend part of their personal time contributing to open-source projects. By doing so, they learn new technologies, get feedback on their coding abilities, and otherwise grow and develop. This is a benefit to the company they work for because it makes them more valuable as employees. However, it can create a problem if their open-source work conflicts in some way with the company's business.
A company may have legitimate concerns about work employees do in their spare time. If the open-source work is similar to an employee's job then there is the danger that the employee will disclose proprietary information concerning technical ideas or business plans. This could make it impossible to file patents on work the company has done. Likewise, the employee might inappropriately take ideas or code from the open-source project and use it in a company product, thereby tainting it.
Even when an employee's open-source work and normal work assignment are in different areas, the company might have a product that competes with that of the open-source project. That can create a conflict of interest for the employee.
Many companies require their employees to sign an agreement when they are hired that specifies that the company owns anything that the employees invent. Students who are receiving support from their university may be in a similar situation. If the employees or students contribute to an open-source project, then their employer may claim ownership of their work. There have been several stories reported at places such as Slashdot in which this has indeed happened and people had to stop their participation in the open-source project and have their code removed from it. This is bad for the project, is very bad for the individual, and gives the company a bad name. No one benefits from a situation like this.
All these potential problems can be avoided by having a simple process for employees to get approval to participate in an open-source project. The process should ensure that the employees understand company policy regarding intellectual property and conflicts of interest. General guidelines should be established and communicated to the employees. These typically include that any open-source work should be done on the employees' own time, should not be done while at work or using company equipment, and should not be similar to what their normal job duties are. A form amending the original employee agreement should be signed by an appropriate-level company executive and the employees should receive a copy. The form should state that the company gives up any claim to the work done by the employees as part of the open-source project and that the employees have the right to assign their copyrights to the open-source project.
The need for approval arises largely because of the agreement many companies have new employees sign. One suggestion from Slashdot is that when starting a new job the new employee should rewrite any offending clauses to restrict the scope of that agreement. The following is an excerpt from that posting:
A lot of people think they have no negotiating ability. You do. When you're thinking of signing on with some company, and they send you a boiler-plate contract to sign, don't just sign it and send it back. Read it carefully. Alter it as you see fit, striking out sections, adding sections, and initialing each change. Then sign it, make a copy for yourself, and send it back.
See how much nicer that reads? Now, when you do this, there are two possibilities: either the company will ignore it and hire you, or they will object to your alteration of the contract.1
There will come a time when you need to reduce the number of people and resources devoted to an open-source project that your company has been sponsoring. Because it is an open-source project, this is a much more public announcement than reducing the number of employees working on some internal proprietary product. If handled badly, it can hurt your company's reputation in other open-source projects you sponsor or participate in--developers will question your company's commitment to open source. You can also expect news stories reporting your company's change in focus.
Naturally, how damaging such a reduction in support can be depends on the size and prominence of the project. If it is something as large as IBM's support for Eclipse, then reducing commitment will probably be written about in the mainstream press, whereas if it's a small company with a small project, there might be hardly any notice taken outside that project's community. The community surrounding even a trivial project, however, can be vocal and influential beyond the apparent importance of the project itself, and it is sometimes hard to know for sure who is watching the project. So be wary of how you try to reduce your company's commitment.
Because of the potential for damage to your company's reputation, it is important to have an approval process in place to review any decreases in your participation in publicly visible open-source projects. The last thing your CEO wants is for the press to announce that your company is making major changes in strategy all because some low-level manager has laid off or transferred the employees most visible to one of your open-source projects. We've seen this happen--a company laid off the employee providing the technological leadership for one of their open-source projects--along with the subsequent damage control the company needed to recover from it.
For a small project, all of this may seem like overkill. However, the same steps must be followed whether you are releasing 500 lines of code or 500,000. Of course, it is much easier to do due diligence on 500 lines of source code so it can be released.
To be successful, open source requires fostering a community around the code, and that takes work. At a minimum, someone who understands the code must filter suggested changes and help developers work with it. It also requires an archived mailing list or newsgroup and at least a handful of web pages, including one that lets people download the source code and executable versions.
Most open-source projects are fairly small, consisting of fewer than 20 developers and several hundred users. So, the effort required is only the discussion and coding needed to move the project along. As long as the user community is happy with the rate of progress, the project is alive and healthy. For a mature project there may not be many, if any, changes being made to the code--the community will stay healthy from active discussions on how to best use the software.
Because a small project will have a limited budget (and an EOL project may have no budget), it will probably not be able to afford to have a dedicated website. If your company already has a website for small company-sponsored open-source projects, then you can host your project there. For example, a number of smaller Sun open-source projects are hosted at SunSource.net.2 If your company does not have such a website then you will need to use a free website provider, such as SourceForge.3
For EOLed code that is no longer being supported, but that you don't want to die, the amount of effort needed to make it open source may seem to be orders of magnitude more than the work you expect your group will put into the code in the future. Remember that open source is not magic: It takes a lot of work to create a community and make an open-source project successful. You will still need to determine an appropriate license for the software. To give a community a chance to grow, you should expect that you will need to commit one or two engineers for at least a year to engage with the community and to continue working on the code.
For a product that you are about to stop supporting, you may just want to provide the source code to current customers so they can continue to use it. That is, you want to keep your customers happy even though you are discontinuing the product, but you are not interested in creating a community. In such a case, it may be sufficient to make the source code and supporting material, such as build scripts and internal documentation, available for download on your regular corporate website. You should also make sure that there is an email list or forum set up so that your customers can help each other--plan for some of your engineers to participate on that list.