Joining an Existing Open-Source Project

License Issues

Before joining an open-source project you need to check that its licenses are compatible with your business goals. For example, suppose that you are planning to combine the existing open-source code with proprietary code. If the project is using a GPL-style license then you will not be able to do so. However, if it is using any of the other common open-source licenses, including LGPL, then you will be okay.

Becoming a Good Community Member

In theory, your involvement can be as limited as merely contributing a few bug fixes or small new features. Generally, your business goals will require you to do a bit more, and you will need to actively participate in the project and establish yourself as a valued community member.

Each open-source project has its own flavor, just as each Internet newsgroup or mailing list does. People are known to the community by their previous posts and contributions. It is very important that, before you start posting to the project mailing lists, you first lurk for a bit. Read over some of the mailing list archives to get a feel for how the project operates: Who is influential, what are the current major issues, and how are issues decided? You should also search the archives to see what has already been discussed about your particular areas of interest.

When you first post to the project to announce how you want to be involved, it is very important that you acknowledge the good work already done and explain how you plan to add value. You want to avoid appearing arrogant. You may also need to alleviate people's fears that your company is somehow trying to rip them off--sometimes just explaining why it is important to your company is enough to do that.

Keep in mind that you need to establish your reputation as an individual working on the open-source project. Other people working on the project don't care so much about your position at your company. What they care about is the quality of your posts and code contributions. The more they respect you, the easier it will be to work with them.

This might be a good place to mention some reasons why you should contribute any modifications you make back to the open-source project. First, it's the right thing to do. The community has made the code available to you, so you should return the favor by giving it any improvements that you make to the code. Second, it will help you build better relations with the community. If you are perceived as a good community member, then you are more apt to be listened to in discussions about the project's future. Finally, if you do not contribute your changes, then with each new release of the software you need to manually add your changes to the latest version of the source code--if the code has changed in ways that are incompatible with your modifications, you may need to do significant work to reincorporate your changes. When you give your changes back to the community, people who make additional changes will do whatever work is necessary to keep your code from breaking. By not contributing your changes, with each release you will need to do that work; you will be paying what is often called the stupidity tax.

The Open-Source Development Process

The key to open-source development is that it is an open process. This is especially to your benefit when joining an existing open-source project. By looking at the project's website, you should be able to learn everything you need to know about how the project is organized. In particular, you can read the project road map to get an understanding of what development is planned. You can identify the individuals responsible for the modules you will be working on. You can read the mailing list archives to get a sense of the project's history and character.

As you begin to work on the project, you need to make sure that you maintain this openness. Make sure that you use the project's public mailing lists and not a list internal to your company. Involve the community in any major design decisions that you need to make.

Being open in your intentions is quite important in your dealings with the project's module owners. These are the people who have the final say as to whether your proposed contributions are accepted into the official code base. That being the case, it is important that you post a message announcing your intentions--what you want to do and how you plan to do it--before doing any major work. This will give the module owner and the other developers a chance to comment on your plans and evaluate how they fit in, or do not fit in, with the community's development plans. It is likely that you will need to make your work more general or extend the functionality to satisfy the rest of the project. It is also likely that the revised plan will be better overall. Note that if all you want to do is implement an API to your own proprietary code, that will not get much, if any, community support.

Some of the discussion may become a bit heated; many developers express themselves quite bluntly. Don't let the flames get to you. Remember that many of the people you are dealing with are volunteers and some may be quite inexperienced. Your replies should be aimed at the community and not at the "idiot" who just flamed you. Refer to the earlier section on "Posting Etiquette" for more on how to handle yourself when posting.

For more details of the day-to-day mechanics of an open-source project, please see the earlier section "How to Do Open-Source Development."

Getting Your Contributions Accepted

To be effective when doing open-source development, it is very important to create realistic expectations on both sides. We have already talked about making sure that the community, and especially the module owners, have a clear expectation of what you want to contribute to the project. This will greatly increase the chances that your code will be accepted when you finish it. Another factor in your favor is that most people running an open-source project want their application to become popular and be used everywhere, so if your company is interested in modifying it a bit so it will be of interest to more people, you already have a leg up.

It is also important that you have realistic expectations about how the open-source project functions. For example, it may release a major stable version once a year, so if it has just finished a release cycle, then anything you contribute won't be officially released until the next year's major stable version. Likewise, if the project is in the middle of a release cycle, there may not be much community interest in discussing the wonderful new features that you are planning on--you may need to wait until the release is done before people have the energy to discuss major new features.

Another potential problem you face is that the particular module owner you are working with may be very slow in accepting your contributions. This may be because the module owner is busy with other matters or doesn't have much time to devote to the project. It may also be that your team of several developers is writing code much faster than the single module owner can digest it. If this is the case, you need to gain the trust of the module owner so that you can be allowed to check code in directly. It helps if you respect the coding style already used in the module when you write bug fixes, patches, or small changes.

A major role of the module owner is to guarantee the quality of the code base by screening contributed code. Some module owners are happy to share this screening function with developers who have shown that they are competent. Although module owners have the last word on what goes into their module, they are fine about letting delegated individuals check in the code when it is ready, as long as the general design had been discussed on the project's mailing list beforehand.

Sometimes, however a module owner refuses to delegate, and this can create a major problem. Some module owners insist on understanding every line of code in their modules, which is fine for small modules but may be impossible for a very large one. This is especially true for some original project owners who have never been willing to delegate responsibility to the various modules but instead insist on being a bottleneck that all major changes need to go through. If this turns out to be the case and the module/project owner is unwilling to change, you may need to muster community support for sharing responsibility. Otherwise, your only option is to fork the project. That is what happened with Emacs back in 1992: The XEmacs project came about when Lucid Inc., tried to contribute major changes to the display code and Richard Stallman refused to accept them.1 A decade later, the two projects still remain separate.2

A successful example of a company joining an existing open-source project is IBM's work on the Linux operating system. In an interview on Slashdot, the IBM Linux Kernel hackers talked about getting their changes accepted into the Linux code base:

Question: Is Linus accepting your changes well? How directly do you submit patches, and what are your experiences on the overall Linux kernel development style?

Answer: Linus himself is wonderful about accepting patches on technical merit alone. He doesn't "grade" them differently if they come from ibm.com or mit.edu. We submit patches the exact same way that everyone else does: append the patch, mail to Linus and CC linux-kernel. If it's good, it gets in. If it sucks, you get flamed.

However, the submission process can be more complicated than first appears. Often, you need to figure out who is maintaining a particular area of code, followed by talking to them to gauge if someone else is already working on the same thing. Once you submit your code to them and the appropriate list (isn't always lkml ...), you may not get a response. This can be discouraging, but you have to find out why, or just simply resubmit, over and over and over. But, once you have a reputation, it does get easier to get quicker responses.

Sometimes it's frustrating when you've put a lot of effort into something that doesn't get accepted, but there's normally a good reason for it. Even work that doesn't get accepted can influence other people's thinking and development in the future. On the flip side you can also just point out problems and other people fix them for you, so in general you win more than you lose;-) 3