Skip to main content

Creating and Managing an Open Source Project, Part 1

July 28, 2005
Michael Nascimento Santos

{cs.r.title}




Contents
Things to Consider Before You
Create Your Project
Picking a License
Requesting a Project on java.net
Conclusion

The growing popularity of open source software benefits everyone. From simple utility classes to full-blown IDEs, it is hard to find a Java developer that is not using some open source piece nowadays, even though he/she may not be aware of it. By feeling open source has done a lot for them, or by seeing how other projects have been successful and grown in quality, or even because their company wants them to do so, many developers are willing to create their own projects.

However, there are many hard decisions to be made, and some of them cannot be undone easily. Besides that, many of these projects fail miserably because of misconceptions people have. The aim of this series of articles is to explain when you should create your own open source project; how to do it, and how to organize it so it succeeds. Although many of the principles explained here apply to all open source projects, this article focuses on Java-based projects and gives detailed information about java.net's tools and its project submission process.

Things to Consider Before You Create Your Project

It might seem tempting to simply look for the "New Project" form and start filling in the data, but it is nice to think about a few points before doing so.

The first thing to consider is whether a similar project currently exists. Some people suffer from the "Not Invented Here" (NIH) syndrome, but it causes a lot of pain. Managing an open source project demands a lot of time and effort (and money, sometimes) and it is usually better, easier, and cheaper to contribute to an existing project rather than creating a new one. There are some factors that may require the creation of a new project, such as license incompatibility (more on this later) or a "closed" development process, but it is still better to talk to the owners of existing projects and discuss these issues first. Many of them will do whatever is possible to meet your needs, and then everybody ends up winning.

After that, there is a crucial question you have to ask yourself before you continue: do you think you will be able to maintain it? After all, creating the project is a one-time action, but managing is a continuous, time-consuming task. If a company is not supporting this initiative, it will be a huge effort. By reading this series of articles first, you will understand what is involved and be better prepared to answer this question. For example, a common misconception is that once you create your project, developers will promptly join it and start submitting patches. That is far from truth: unless your project becomes stable, is attractive and useful for hundreds--in some cases, thousands--of people, has good documentation etc., the initial committers will be the only developers writing code for a long time. Therefore, it is indeed a huge responsibility.

Another important step is to make sure you will be legally able to use the libraries or frameworks you intend to use. Licenses are really tricky to understand on their own and when you combine them, it only becomes messier. Although some license issues will be addressed by this article, it is likely you will need some expert advice with this unless all pieces are under the same license.

A hard issue is to determine who will be the copyright owner for the code. Some contracts require you to grant copyright of everything you produce to your employer, or your project may actually be sponsored by the company you work for. This is the easier case, actually, since it only allows one possibility. It can be a surprisingly tougher decision when you do have a choice. Some people do not like contributing to projects that "belong" to individuals or corporations. Besides that, the initial code might have been written by a small group of developers and the others may feel the copyright owner is the only one taking credit for their work.

Finally, there is a major decision to be taken that deserves a section on its own: the project license.

Picking a License

Many people have been complaining recently about the need to reduce the number of licenses available, but since this hasn't happened yet, dealing with them is still necessary (and tough).

Although many members seem unaware of it, java.net already contains a page that discusses the differences between the licenses currently available at the site. Since the most important bits are explored there, I advise you to refer to it for more information, but I will mention a few points I personally consider relevant:

  • BSD is the most appropriate choice if you want people to use your code in whatever way they like. It is important to keep in mind that this might mean "closing" it and selling it, thus profiting from your work.
  • The Apache license is a little stricter than BSD and protects developers from patent litigation from other developers or contributors, but does not prevent your work from being incorporated into proprietary software, even in modified form.
  • The Mozilla Public License (MPL) and the Lesser General Public License (LGPL) are quite similar in some aspects (such as in requiring modifications to the original code to be published under the same terms), but LGPL is more restrictive, since it grants users the permission to reverse-engineer applications using the library in order to allow changes made to a modified version of the library to be debugged. In many (if not most) countries, there is actually no legal way of preventing a user from reverse-engineering software (except for malicious purposes), but even so, this fact tends to scare a number of managers and legal departments. There are other differences between the licenses, but LGPL is a better choice if the library might be combined with GPL software in the future.
  • The General Public License (GPL) is a good choice if you want your code to be "free" forever. However, note that everyone using your code as part of his or her work will need to distribute the new code base under GPL as well. That is why it is said to be a viral license, but also it is why it will keep your code free forever. Whether that is an excellent or a terrible thing is up to the reader to decide.
  • If there is no strong reason against it, it is usually a good idea to license your open source project under the same license used by the other libraries it depends upon. This will be very helpful if you ever need to modify the code of a third-party library in order to fix a bug or to implement an enhancement.

There are other licenses for documentation-only projects and for projects connected with some Sun projects, such as the JDK. A complete list of the licenses supported by java.net is available for further information. Remember to read the license text carefully and to follow the instructions contained in a license on how to apply it to your work.

After you have chosen a license, you are ready to request a project on java.net.

Requesting a Project on java.net

As obvious as it may seem, you actually have to be a member of java.net before requesting a project. If you still are not, become a member by filling in the required information.

Once you have become a registered member, you should start the process by accessing the "Request a project" page. After you click on the "Start here" link, you will be led to the first of two long-form pages you will have to fill in. These pages might seem a bit intimidating at first, but it is actually quite simple to provide the required information. Let us start examining the first half of page one, as seen in Figure 1:

Figure 1
Figure 1. The first page of a java.net project request--click image for full-size image.

For the "Project Name," you should type a lowercase sequence of characters (0-9 and dashes are also valid if they are not used as the first character, as mentioned in the page) that will later be used as part of the domain name of your project and for other artifacts. For example, if you named your project "testproject," its java.net domain name would be testproject.dev.java.net. You should probably copy this name and paste it to a text editor, since you will be required to enter it again on the second page.

The "Project Title" is usually an expanded or formatted version of the project name. For a project named "testproject," this could be "Test Project," for instance. If the project name is or contains an acronym, you might want to use its expanded version for the title. The "Project Description" is intended to explain the purpose of your project and is displayed along with the name and title in the project directory. You should probably take a look at the Directory to understand how they work together. The display format is similar to:

Project Title (projectname)
Project Description

So while your project name should be an easy-to-type single word, the project title is usually what people will call your project, and the description describes what it does. This might seem simple--it is, in fact, once you understand how these values are used--but some project titles in the directory are actually project descriptions, for example.

You also need to choose to which community your project will belong. A community not only groups related projects, but also helps to promote them, provides all of the necessary infrastructure, and defines a set of guidelines and rules for them. Communities have different rules for incubation, graduation or even things such as CVS layout. The current set of communities includes:

It is recommended you visit the home page of communities your project seems to fit into. This will give you a better idea about the way they work and their requirements for project approval. Depending on which community you choose, reading the instructions carefully could be the difference between having your project approved as soon as a community manager gets to it or receiving a message asking for more information.

The "Topics Related to your Project" section is used to better categorize your project and to make it easier for people to find it in java.net's directory. Although you may not be sure whether you will use a specific technology, for example, choose the topics that best suit the main goal of your project.

Let us now examine the second part of the page, shown in Figure 2:

Figure 2
Figure 2. The first page of a java.net project request--click image for full-size image.

The "Existing Membership Size" is a rough estimate that serves as extra information for the community managers who will review your project. If there is already a small community that supports your project, it is more likely the project will be approved.

After filling the very important (but pretty obvious) "Project Manager Contact Information" section, you are supposed to indicate which Services you intend to use for your project. Not choosing a service does not mean that you'll never be able to use that service; this information is meant for those reviewing your project submission as well as for statistics. For example, if you already host your project somewhere else, it might be better to create a linked project at java.net. On the other hand, if there are a lot of services you want to use, you might choose to move to java.net completely. So, while this information will not prevent you from using the services you do not select, it is important to be as accurate as possible.

If you have an existing, external RSS feed that is used for project news or announcements, registering that URL will help community managers to collect information that might be used to publicize your project. Finally, the "Other Notes and Comments" can be used to provide extra information you consider important, such as mentioning the project is already hosted elsewhere, explaining why you are moving to java.net, etc.

After you have filled all of the required fields, clicking on Continue will take you to the second form, shown in Figure 3:

Figure 2
Figure 3. The first page of a java.net project request--click image for full-size image.

The Project name, Summary, and Description work exactly as the Project Name, Project Title, and Project Description from the previous form. It is important that the value for Project Name in this form is equal to the value entered on the first page; otherwise, it will not be possible to relate the directory information to the java.net project itself.

To finish filling the form, simply select the license you have chosen, leave "Use project index.html" unselected for now (this setting can be changed anytime you want), select a language for the emails sent by the system, and leave the Artifact code unchanged as well. Finally, click the "Create project" button to complete your submission. Congratulations! Your project has been created and just has to be approved by a community manager before it is publicly available.

Conclusion

In this article, we examined when it is worth creating a new project, discussed license issues, and explained how to create your project at java.net.

However, once the project submission is done and approved, there is much more to be done for your project to evolve and succeed. In the next part of this series, we will analyze what is involved in organizing and maintaining an open source project and how java.net services can be used to help it grow in a controlled, positive manner.

Michael Nascimento Santos is a seasoned developer with more than 8 years of experience with the Java platform, from J2ME to J2EE, and over 14 years of pratical programming experience.
Related Topics >> Community   |   
Article Links >>