Finding your way around SourceForge
by Barry Cornelius, Sebastian Rahtz, Stuart Yeates, Ross Gardler on 27 March 2007 , last updated
Archived This page has been archived. Its content will not be updated. Further details of our archive policy.
Introduction
SourceForge is a well-known hosting site for free and open source software development projects. It currently hosts more than 149,000 projects, with 1.5 million registered users and, when academics wish to study open source development communities, SourceForge is often the site that they examine. The enormous amount of material on SourceForge, and the large number of facilities which it offers, can be intimidating or confusing for new users. Fortunately, SourceForge adopts a consistent structure. So, once you are familiar with the way in which the site works with regard to one project, you will find it is applicable to other projects.
This document aims to provide a simple guide for those encountering SourceForge for the first time. It is designed for users who are looking for open source software solutions. It therefore covers tasks such as finding, assessing, and downloading software, but not the creation of a new project or uploading content.
Overview of SourceForge
SourceForge is a hosting provider that provides services free of charge to open source projects. The services it provides include web hosting, version control repositories, bug trackers, software downloading tools, and more. It also offers a mechanism whereby users can identify the project administrators and developers of SourceForge-hosted software in order to donate money to them through Paypal.
With few exceptions SourceForge has no direct influence on the actual software itself. In other words the software is not designed, written, tested, debugged, packaged, or owned by SourceForge in any way. The open source developers working on the projects are responsible for all of these tasks, they simply use SourceForge as a communications point.
Finding projects on SourceForge
SourceForge can be a good place to start when you are searching for an open source project. However, there are a large number of significant projects that are not hosted on SourceForge. When looking for the most appropriate software for your needs you should also ask for recommendations from colleagues, search the web using your favourite search engine, and search on other software catalogue sites such as Freshmeat.
Searching for projects on SourceForge is easy. To locate a project, just use the search box in the top navigation, searching for the project name, or some keyword they may have used in their description. Thus a search for something like TeX returns a list of results like that shown in the figure below.
Each entry in the returned list provides quite a bit of detail about a project. Most importantly, it provides a short description of the project and information such as an activity rating, a rank, the date it was first registered, the date of the last release, and the number of downloads from the project. All of this information can be used to help choose the most appropriate project for your needs. Each of these items is considered, along with other selection criteria, later in this article.
Having completed a search it is possible to display additional information about each project. This additional information includes things like the programming language used, the licence the software is released under, the operating system used, the intended audience, and the current development status. Again this information can be useful in selecting which projects to take a more detailed look at. To display these additional details click on the “Details” link at the head of the results list.
For many searches the number of results can be very high. It can therefore be useful to filter the results according to certain criteria. For example, you may only be interested in projects that have released files and use a specific type of licence. Fortunately, SourceForge makes it easy to filter your results in this way. Simply click on the “Filter” link at the head of the results list and add your chosen filter category using the options that are presented.
Browsing rather than searching
An alternative to searching is to browse the Software Categories that are given on the SourceForge home page, as shown below. Software categories do not provide complete coverage and are entirely self-reported, but remain valuable for finding projects for which there are no obvious search terms. Browsing can also turn up some gems within your specific area of interest.
It is worth noting that once you have clicked on a category on the home page you are taken to the search results page. This allows you to control the diplayed information and filter the results in the same way you can for searches. You may also notice the expandable tree view of Project Topics to the right of your results list (see below). This allows you to further refine/expand your returned projects by sub or parent categories.
Assessing a project
There are three main sources of information about software on SourceForge: the project summary page, the project home page, and third party information.
The project summary page, at http://sourceforge.net/projects/[PROJECT-NAME], displays a set of automatically generated meta data about the project. This page has the virtue of uniformity since all software projects hosted on SourceForge have a project summary page displaying the same details. This makes it easy to quickly establish the key facts about a project.
The following picture shows the top of the project summary page for PhpMyAdmin (a database administration tool written in PHP).
Note the tabs that allow easy navigation to some of the important community tools for the project. These will become important to you if you start to explore the project in more detail. For now, let us skip past them and look at the summary details available to us. First, there is a paragraph giving a brief introduction to the project. On some projects there will also be a screen shot image to the right of the description. This can be useful for getting an immediate feel for what the software release history of the project looks like. Clicking on the screen shot image will take you to a larger version of the image and also make other screen shots uploaded by the project available to you.
The description section may be followed by a Download link enabling you to download the files of the project; this link will not be present in a project that has not yet released any files. Not having released files is an early indicator to the viability of the project for your needs. Do you really want to have to dig into the source code in order to achieve what you want to achieve? Conversely, you may be very comfortable working with unreleased source code.
The next section provides some useful information about the software release, such as what operating system it is designed for, what licence it is released under, and what categories the project is filed under. The extent of the information available in this section is dependent on the project administrators, and is useful if your choice of software is constrained by certain requirements such as a particular programming language or a specific licence restriction. However, you may well have already filtered out projects that do not meet these criteria when you filtered the search results earlier on.
Next there is a Latest News section. This is a simple area in which projects can announce important activities within their project. Not all projects use the SourceForge news facilities so the lack of news here does not mean that the project is inactive. It simply means that they use other mechanisms for making announcements.
Below this summary section there are two columns labeled Public Areas and Project Details. These areas provide detailed information about the project and its activity. The following sections look at these areas in more detail. However, it is important to be aware that some projects opt out of using some parts of SourceForge. Consequently, specific information will not always be displayed in these sections. This does not mean that a project is not active in that area, it just means that they are not using the SourceForge hosted facilities for that particular tool.
Public Areas
The Public Areas section of the project summary page provides access to all the major areas and files connected with the project. Often, the activity in these areas is an indicator of the strength of the community around the project. It is often stated that any open source project is only as strong as its community. Therefore, you should evaluate the community when you evaluate a project. Clearly, in a young project one should not expect a particularly active community, however, one should expect to see the project being run in such a way that interested parties can help build a strong community.
Below is the Public Areas entry for PhpMyAdmin.
In the following sections each each of these public areas is examined in more detail, but first, it should be reiterated that different projects use SourceForge in different ways. Some use it as their main project site, taking of advantage of all these sections. Others use SourceForge simply as their principal route for distribution and download of source and binary files, whilst maintaining an entirely separate site for their software development and project community. Activity in these public areas can be an indicator of a strong community, however, a lack of activity here does not necessarily indicate a lack of community. In fact, many projects disable some of these public areas and so they may not appear on the project summary page at all.
Bugs
If you access the Bugs link, you will be taken to a page listing the bugs that have been reported. By default, only the bugs that are Open are listed. The page also provides a means for anyone to report a new bug.
Having lots of open bugs is not necessarily a bad sign. It means that the users of the software are recording bugs so that they can be fixed. If a project has no reported bugs then it could indicate that it has no real users either. SourceForge provides tools that allow you to determine how likely a bug is to be fixed by the project developers.
It is also worth considering that a bug is not necessarily a problem in general use. It may only emerge when specific circumstances are in operation. So again, a large number of bugs is not automatically an indicator of poor quality code. It can be worth sorting the bugs list by priority to see how many serious issues are currently open.
One final thing to consider is that the bug tracker describes bugs in both released versions and unreleased versions of the application. If a project has configured their bug tracker on SourceForge accordingly, you will be able to get an idea of the status of released versions by only displaying bugs listed against a specific version number.
Support Requests
If you access the Support Requests link, you will be taken to a page listing requests for help in using the software. The page also provides a means for anyone to submit a new request for help.
An active support mechanism is very important in an open source project. It is where new users will get help and where developers can get an understanding of how users interact with the system. Many open source projects have commercial support companies affiliated with them. However, it is important to understand that support provided through the SourceForge support channels is is not paid for and consequently you should not expect to see immediate and complete responses to support requests. However, you should be able to see meaningful responses that assist the user in learning how to fix their own problems.
Many projects do not use the SourceForge hosted support forum. They may choose to offer support through a mailing list, or a self hosted support tool. If the support option is not displayed on the SourceForge page, you should look for a mailing list or for support details on the project’s website (see below).
Patches
If you access the Patches link, you will be taken to a page listing suggested patches to the software. The page also provides a means for anyone to submit a new patch.
A patch is a small piece of code that fixes a bug or adds a feature. Patches are contributed by developers who do not have write privileges for the project’s version control system and so cannot make the changes directly in the code base.
Different projects manage patches in different ways. Many do not use use a separate patch queue, but use the standard issue tracker where patches are attached to the bugs or feature requests they relate to. Therefore the lack of patches in the patch queue on SourceForge is not a reliable indicator of project health.
If the patch queue is in use then you should take note of the number of patches that are left outstanding. In a healthy project patches will be reviewed quickly and, where appropriate, will be applied to the core code base. Where the patch is deemed to be inappropriate the reasons for not applying the patch should be explained in the comments of the patch record and the record be moved out of the queue. So, in a healthy project you should see a small number of patches outstanding at any one time, with a reasonable turnover rate for new patches being contributed. Later in this document there is a description of how to discover how quickly patches are dealt with.
Feature Requests
If you access the Feature Requests link, you will be taken to a page listing requests for changes to the software. The page also provides a means for anyone to submit a new feature request.
Feature requests can be made by anyone, although some projects require that you are logged in to your SourceForge account. (An account is an identifier of membership and also a personalized user interface in SourceForge; this allows the user to create, manage and contribute to software projects, provide a personal profile and contact data, receive payments, etc.) Feature requests are extremely useful for developers in understanding what their users need. However, they are not very useful for evaluating the health of a project. Open source projects are run by volunteers and a feature will only be implemented if it is felt to add value to a large number of users or if the user requiring the feature adds it themselves. Therefore, it is common to find that projects with large user bases have large sets of unimplemented feature requests.
Public Forums and Mailing Lists
Most open source projects provide a means for people to ask questions. This can be done using forums and/or mailing lists.
The activity on the project’s mailing lists/forums is a very good indicator of the health of a project. You should not necessarily be looking for volume of mails, but rather quality of discussion. Projects can be successful with small communities, they can also be successful with large communities. However, the community must always be supportive of new users and developers, as well as being informative, polite, focused, and welcoming. Reading some recent archived posts to the forum or mailing list can be a good indicator of the “atmosphere” within a project. A good atmosphere will be welcoming to new participants and will generally indicate, at least a potential for, a strong community.
CVS/Subversion Repository
One of the key aspects of open source software is that it is possible for anyone to see the code of the software. Although some SourceForge projects store their source elsewhere, many store it at SourceForge. If a project stores its source at SourceForge, this section provides a link to the code repository. CVS and Subversion are the version control systems supported on SourceForge.
It is possible to browse the source tree from a web browser. For the technically minded this can be a very useful activity, allowing one to get a feel for the quality of code contributed to the project.
It is also possible for visitors to “check out” the code from this version repository. However, this is outside the scope of this user focused document.
Project Details
The Project Details section contains various facts about the project. Below is the entry for PhpMyAdmin.
There is a great deal of information in this list, most of it is reasonably self explanatory. However, there are some entries that are very useful when assessing a project, and these are discussed below.
Project Admins and Developers
These sections indicate the number of administrators the project has, along with the number of developers. Generally speaking, a high number of administrators and developers is a good sign with respect to community health, and therefore project health. However, before making a judgement on this matter one should ascertain the governance model in use. Some projects use a benevolent dictator model, in which case there will be only a single admin and developer. In such cases there should be increased activity in other areas, such as the patch queue, since developers are not able to make direct changes to the code base.
Generally, a larger number of admins and developers is a good indicator of health because, over time, people’s priorities and commitment change, It is therefore natural that the active developers on a project will change over time. Having a high number of developers does not necessarily mean that they are all active at any point in time, but it does mean that the project has attracted developers during its lifetime. It is possible to gauge how many people are currently active in a project by examining the version control system and reading the mail list archives.
Although a large developer base is a good sign, it should be recognised that there are many examples of successful projects with a small number of developers. So one should be careful to consider the developer figures alongside other metrics available on SourceForge. For example, a new project is unlikely to have attracted a large number of developers.
Development Status
This is the self-reported maturity of the project. It is worth bearing in mind that open source projects are often very conservative with their use of terms like “stable”. Furthermore, there is no concrete definition of when each of the various status codes should be used. One project marking itself as “beta” may be of higher quality and have fewer issues than another project that has labelled itself as “stable”. Therefore, you should use this classification as a guide only.
The various status codes available are described below, along with a description of the most common usage of these terms and details of when you should consider projects marked with a particular status.
- Planning
- No real decisions regarding the project have yet been made. You are only likely to be interested in this kind of project if you are about to start a project to meet a specific need and this one sounds like it has a considerable overlap in its goals.
- Pre-Alpha
- A project in this state has usually made some initial design decisions but has not yet reached a stage of having an implementation to evaluate. You are likely to be interested in a project at this stage if your needs seem to overlap with those of the project and if you are willing to share your knowledge and experience in finalising the design and/or creating an initial implementation.
- Alpha
- A reasonable set of features has been implemented and that implementation is now under active evaluation. There is no guarantee that the code in use will remain unchanged and so it should not be used in production. You are likely to be interested in a project like this if it appears to cover some or all of your requirements and you are willing to help test it for suitability in your domain. Be prepared to work with the community by giving feedback and, if appropriate, providing design refinements, and code patches (typically bug fixes and new features).
- Beta
- A project in beta has reached a stable point with respect to its design. However, the implementation of that design has yet to be fully tested. You are likely to be interested in such projects if the feature set covers some or all of your needs and you are prepared to work with the project community by providing contributions such as bug reports, documentation and code patches.
- Production/Stable
- Once a project has been adequately beta tested it will enter a production/stable phase. Such projects can, in theory, be used in a production environment as they will have been fully tested in the beta phase. You are likely to be interested in projects like these if you need a solution that should not require a great deal of involvement from yourself at the code level. However, you should still be prepared to contribute back to the project through bug reports, documentation and user support forums.
- Mature
- A mature project is one that has been in production for some time and has proven itself to be stable and reliable. It is not uncommon to find that mature projects have started work on a new version of the project code that improves on the design and implementation of the mature product.
- Inactive
- Inactive means that none of the developers are currently working on the project. However, an inactive project may still be useful and if so you can contact the registered project administrator and consider reactivating the project. Therefore you will be interested in such a project if you feel that the existing design and code base is of use to your situation.
Registration Date
This is the date on which the project was registered with SourceForge. Some projects had an existence before they used SourceForge, so this is not necessarily the same as the founding of the project. In itself the registration date is not very useful information. However, other metrics should be interpreted with the registration date in mind. For example, a project that was registered in 2001, but is still marked as being in the planning stage is probably inactive, whilst a project registered two months ago with 10 developers either has a life outside of SourceForge or has extremely low barriers to entry into the developer pool (which may or may not be a bad thing, it depends on the quality of those developers).
Activity Percentile
This is a fairly crude measure of activity within a project in comparison to other projects on SourceForge. An Activity Percentile of eighty percent means that the project was more active than eighty percent of all other projects on SourceForge during the given time period (a week on the summary page). The Activity Percentile is somewhat biased towards projects which use many of the SourceForge tools, because each use of a tool is seen as an activity. As a general rule truly active projects have figures of above eighty percent.
There are many more activity statistics available from SourceForge which will be discussed in more detail in the next section.
Project Statistics
SourceForge collects a large number of statistics about projects it houses. There are various points at which you can access this information, the most consistent is by clicking the “Stats” link in the upper right hand corner of any project screen. This will take you to a summary statistics page that shows four graphs like those shown below. It also displays the same data in tabular form.
These graphs, and the more detailed ones available from the links at the top of the statistics summary page are perhaps the most useful in determining the health of any project. However, like all metrics on SourceForge you must interpret them within the context of the project as a whole. For example, a new project is unlikely to be seeing considerable traffic to its web page.
Generally speaking you should be looking for a gradual upward trend (or at the very least a stable level) in all graphs that indicate community interest in a project, such as “Project Web Traffic”, “Sourceforge.net Traffic”, and “Downloads”. A dwindling interest in a project is sometimes one of the early signs that the project has reached the end of its useful life. There may be another, newer, project that is doing things better, or perhaps the need for this project has simply passed. Nevertheless, if you find the project interesting the levels of interest from third parties may not be relevant to you.
When evaluating activity in a project using these statistics be aware of the time frame being displayed in the graph. It is often set to a seven day period which is not really of interest when evaluating a project. It is possible to change the time frame displayed by selecting a longer time period from the drop down box below the graphs.
Another useful measure is the version control activity. Generally, you want to see regular activity. However, in a stable project this may not be necessary. That is, a stable project may have no bugs to fix and no new features to add. Since open source activity is dependent on the needs of its user and developer community a stable project that meets those needs adequately will not see much activity on its code base.
The Project home page
The project home page is the gateway into the project website, a place where the project can freely describe itself, and typically focuses on what the project members perceive as being the important attributes of their software. This page is often more helpful than the project summary page when deciding whether the software might meet your needs. However, many open source projects find it difficult to keep such marketing materials up to date. Effort tends to go into the code rather than the marketing aspects of the website.
A further problem is that this content is generated by the project itself and so will always be less than impartial. Clearly some independent input when selecting software is always advisable. Sources of more impartial information range from your immediate peers (who have needs closest to your own), independent reviews, articles, and reports.
Nevertheless, the project website will provide a great deal of useful information. In particular you should be looking for a community focus within the project website. At the very minimum you should find some getting started docs, information about the governance model in use, and a description of how to get involved with the community as a user and/or developer.
Downloading software
Nearly all projects on SourceForge use it to provide downloads of their software. One of the advantages of using SourceForge for this is that the download section of SourceForge is mirrored around the world, giving fast local downloads for many people.
Once you have done your desk research by reviewing the SourceForge project site, the project’s own web site, and you have consulted with third parties (where possible), you may decide you want to try out the software. At this point you need to download the software.
You can access the Download section for a project from any project page, simply select Download -> Browse All Files from the menu bar at the top of the project section of the page. This will take you to the downloads summary page that presents information on the different packages that you can download from that project.
Each package is presented with information about the latest release version, date of release, a link to the release notes, and a monitoring facility. Finally, there is a link to the actual download page for that package.
The monitor facility is very useful for projects you are using. By clicking the monitor link (once you have logged in to your SourceForge) account you make a request to be notified whenever a package receives a new release. This is useful if you are a user of the software but do not want to subscribe to any of the mailing lists. Clicking on the monitor link a second time will stop the notifications.
Which package and release you need is dependent on your involvement with the project. Users will normally want the most recent stable release. However, those interested in using the software as part of a development project may be interested in the alpha or beta releases (see above for definitions). Unfortunately, every project uses a different naming convention for their packages so it is not possible to provide a complete reference to typical package names.
If you are still confused a good project website will provide you with a page describing each different package and its target audience. Failing that you may find information in the release notes linked to from the summary page (via the little notebook icon). If you remain confused then the user mailing list or forum is the place to go.
Once you have decided which package you wish to download, click the download link. This takes you to the release section for that package. On this page you will be able to download any released version of the software. Here you are faced with a choice again, which one of the displayed downloads do you actually need?
As with packages, each project manages release downloads differently However, one thing that is consistent is the use of the architecture information. Within the downloads table the architecture column shows which computer operating systems the downloaded can be run on. For example, Platform Independent means it should run on any computer operating system, Win 32 means it is intended for modern Windows platforms, etc.
Many projects also have a number of different versions of a package listed on this download page. The advice here is similar to that above, users will generally want the latest stable release, usually indicated with the word stable, or with the absence of the word alpha or beta.
Those interested in working with the developer community, or embedding the software in another product may prefer to download the latest source code from the version control system. However, it is generally best to avoid this unless you are experienced in compiling software yourself.
Instructions on how to install, configure, and run the software is usually provided on the project’s website or in a README or INSTALL file. Typically one or both of these files will be in the top level of the zip, jar, or tar file you download. A few highly polished projects even have platform specific installers; if such an installer is provided then this is almost certainly the easiest route to take.
SourceForge Help
SourceForge is packed with documentation which can make your life easier and help you make best use of your time using SourceForge. Look for the Help tab across the top of any page and then select Documentation.
It is well beyond the scope of this document to cover all the subjects available in SourceForge’s own help documentation. The place to start, as a new user, is section B. Using SourceForge.net of the complete documentation set, available from any SourceForge page by following the Help -> Documentation menu option. Other sections of the documentation set cover aspects of interest to project administrators and developers.
If the documentation fails to answer your question there are support forums where you can post further questions. To find them select Help -> Get Support from the main menu at the top of any page. If you are still confused, or think that this document can be improved in any way, please let us know and we will do our best to add details here. Where appropriate we will also pass modifications back to the SourceForge documentation effort.
Further reading
Links:
- SourceForge [http://sourceforge.net/]
- Freshmeat.net [http://freshmeat.net/]
- SourceForge site help [http://sourceforge.net/docman/?group_id=1]
- Google Code, a Source Forge alternative [http://code.google.com/]
Related information from OSS Watch: