Skip to main content

Creating and Managing an Open Source Project, Part 1

July 28, 2005


Things to Consider Before You
Create Your Project
Picking a License
Requesting a Project on

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'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

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, 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
  • The Apache
    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
    (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
  • 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 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

Requesting a Project on

As obvious as it may seem, you actually have to be a member of 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 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 domain name would be 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'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

Figure 2
Figure 2. The first page of a 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 On the other hand, if there
are a lot of services you want to use, you might choose to move to 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, etc.

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

Figure 2
Figure 3. The first page of a 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 project

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.


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

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
services can be used to help it grow in a controlled, positive

width="1" height="1" border="0" alt=" " />
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   |