Google Code is a website which offers free hosting services for open source projects. It provides the core facilities required by a community led open source project. This document is a basic introduction to getting started with Google Code project hosting.
Google also provides a number of other services that may be useful to projects hosted on Google Code, or even elsewhere. There is no requirement to use them, but it makes sense if you need these features since your project members will already be signed in to their Google account and will therefore benefit from the Google single sign on system.
Creating a Google Code project is done using the form shown in Figure 1. Of the fields in the form, the only one that cannot be updated later is the project name which should conform to the specification described in the column on the right, that is, it must be lower case with no spaces.
It is worth noting that your project name will form part of the URL for your project development site, so be sure that the name you enter is the one you want.
Google also limits the number of licence options available to you. In their FAQ they explain this decision as follows: "The open source community has been flooded with lots of nearly identical licenses. We'd like to see projects standardize on the most popular, time-tested ones. The selected licenses offer diversity to meet most developer needs." The licences selected by Google are broadly in line with the Open Source Initiative's list of licences they believe to be "popular and widely used with strong communities". There is also the optional facility to apply a separate, Creative Commons, license to cover the non-code assets in the project.
Once you have submitted the details a new project page will appear in the Google Code site at http://code.google.com/p/<project>/. This page will contain the information you provided in the registration screen. From this page you are able to view the various tools provided and, assuming you are an administrator (which you will be if you registered the project), you will be able to configure the behaviour of the tools for your project needs.
At this stage, it is worth putting a little more thought into the summary and description, since they are the first things potential users see when evaluating a project. The description should elaborate the aims of the software and should contain high-level information written in non-technical language so that newcomers can easily see whether this project is likely to be of interest. It should also contain a brief technical overview, to allow specialists in the field to compare several projects to see which one is best suited to them. Finally it should contain a candid evaluation of the state of the project. If the project is on the drawing board rather than in the deployment phase, users will appreciate knowing this up front, whilst developers will recognise they will be getting in on the ground floor and therefore may be able to influence important design decisions.
Mailing lists are the most important communication mechanism for community led projects. In addition to one or more existing mailing lists, Google Code can be used with Google Groups, another of the Google family of applications. One of Google Groups' most popular features is that subscribers can use it either as a mailing list or as a web forum. This is important as it allows contributors to participate in a way that is most comfortable for them. Another important feature of Google Groups is that it can be used to provide an interface to an existing mailing list, so if you already have a mailing list in operation then Google Groups can provide a convenient interface to it, together with Google's excellent search capabilities.
If you already have a group or mailing list for your project, enter the address of a web page describing the list in the "discussion groups" field. This will ensure that your mailing list information is displayed on your project's Google Code page. You can enter more than one mailing list in the admin form, each of them will appear on the project page. Note that the page you enter must already exist, entering information into this field does not create the list for you.
You should also consider providing a mailing list address to receive activity notifications from Google Code. In this case you enter the email address rather than a website address. This means that interested parties are notified by email of Subversion commits and issue tracker activity. Whether you send these notifications to the same list as that intended for discussion or whether you set up alternative lists really depends on the governance of your project. In consensus driven projects, such as those in the Apache Software Foundation, notifications will typically go to the open developer mailing list, whereas in more closed communities they will typically be sent to a closed list. Google Code allows you to use different lists for each type of notification. Note that for these mail notifications to work your mailing list must accept posts from <project>@googlecode.com.
The Google Code issue tracker allows users to report "issues", whether they be bug reports, feature requests, or installation problems. The issue tracker is a public resource and anyone visiting the Google Code site is able to add issues, examine existing issues and "vote" for ones they feel are important. The issue tracker is a vital tool for communication between users and developers and should be utilised as a project planning tool.
Using the tracker enables project management to prioritise, schedule, assign, and document issues clearly. For many open source projects, issue trackers represent the collective memory of what problems have been encountered, by whom, whether they have been addressed, who is working on them, which future release will contain the changes required and how important users perceive each issue to be. This information has a host of technical, legal, and administrative uses. Used well an issue tracker is key to a project's good management.
The issue tracker in Google Code is not as feature rich as some in the marketplace but does have reasonable customisation options. If your project is of a considerable size it could be argued that the Google Code tracker is insufficient. There are also concerns that the data in the tracker is not currently exportable, therefore if you move from Google Code in the future you may find it difficult to migrate your issue tracker content; though a limited facility to export data from the issue tracker is available, at present it seems to be limited just to the header information, not the content of the discussions. However, the issue tracker is quick and easy to set up and, perhaps most importantly for new users, it is simple with none of the potentially distracting "power user" features of some alternatives. A low barrier to entry for users wanting to report issues is vital to involving those users in your work. The Google Code issue tracker does a great job in this respect.
Google code offers both the Subversion version control system and Mercurial. It is also possible to import to or export from git. These version control systems support distributed development and track line-by-line changes made to every file and document in the repository, tracking who made the change, when and why. This information is vital in tracking intellectual property rights (IPR) in your project but also allows you to easily manage different versions of your outputs and to correct mistakes easily.
The use of a public revision control system is critical to open source projects that wish to engage their user and developer community. It is through the version control system that cutting edge users are able to get the latest development versions of your code and provides the code against which patches will be supplied.
It is beyond the scope of this document to describe the use of SVN in open source development. Detailed documentation on the use of Subversion can be found in the Subversion Book (see resources). For more direct assistance you should consider joining us on our Community Development mailing list.
The wiki provided by Google Code is somewhat limited when compared to some of the popular wiki software available. However, it has one considerable advantage over other wiki tools - it allows content in the wiki to be edited offline and then committed via SVN. This means that it is possible to use the wiki in a much more flexible way than is often possible with a web only interface. Of course, Google Code also provides a web interface.
Google appear to be improving the integration of Google Code's tools. For example, a documented mechanism is provided to perform updates to the issue tracker by embedding commands in version control check-in comments. Such features are very useful in providing an audit trail in your project.
Other integration features tend to be undocumented and should be considered alpha (i.e. they may change). For example, issue tracker descriptions can contain references to wiki pages.
Unfortunately, Google does not publish an API for Google Code. This makes it difficult for third party tools to integrate with the product. However, there are projects working towards creating a better development environment.
By agreeing to the terms of service that Google presents on sign-up to Google Code, you grant Google rights to distribute any of the material you upload to your Google Code project. This does not change the ownership of the material, which will still be yours (if it was before).
On the project administration page there is a drop-down box to change the advertised licence of the project. This constrains a project to a small (but reasonable) subset of open source licences. It also allows one to apply a second, separate license to the non-code assets in a project. Projects should be aware that changing a project's licence is not as easy as changing the item in the drop-down box once there is content in the wiki and Subversion repository since materials will have to be carefully relicenced. Therefore, careful consideration of the licence you choose during registration is important. If you would like assistance with choosing a licence you can make initial enquiries on our Community Development mailing list or, if your project is based in a UK HE or FE institution, you can request a consultation from OSS Watch. Such consultations are free of charge for FE and HE in the UK thanks to continued funding from the JISC.
First and foremost you need to be aware that your organisational policies may advise against (or even forbid) the use of non-approved third party services. However, if you intend to open source your project and you wish to work towards true sustainability via the open source route then it is important that your outputs are available to potential users and community members in an ongoing and sustainable way, even beyond your initial funding. In many cases, using an external facility, such as Google Code, will often be easier and cheaper than creating in-house services for hosting your outputs. OSS Watch will be able to liaise with your organisational policy makers in order to establish an acceptable and realistic policy for both your project and your organisation.
Assuming that there are no organisational barriers to the use of a third party system, one must then choose a service to use. A wide range of commercial and not-for-profit services offer a comparable set of services to Google Code. Each offers a different set of services and a different set of conditions on use. They include SourceForge, EduForge, Savannah, GNA, BerliOS, TuxFamily, Debian Alioth. OSS Watch will be happy to help your project decide on the appropriate home for its outputs.
Many projects are initially associated with an institution, which may consider hosting these services internally. This gives the option of customisation of the tools with respect to the project needs. Such hosting has the additional effect of providing a clear link between the project and the host institution. Such an association may be a benefit or a restriction depending on the intentions of the project. For example, strong association with an institution may prevent some potential contributors becoming involved, or it may be a mechanism by which the institution improves its brand in a given area. It also leaves the project at the mercy of a change of circumstance within the single institution.
Google Code is a good solution for your hosting needs. It is clean, comfortable to use and focussed. However, it is still in beta and there are obvious limitations in its use. In its current form Google Code is an ideal solution for a small to medium sized project that wishes to get up and running quickly and does not want to be confused by a wealth of tools that are not always necessary in a community led project.
The OSS Watch briefing note Avoiding abandon-ware: getting to grips with the open development method provides an overview of best practices that can be applied when undertaking open development using services such as Google Code.
It is licensed under the
Creative Commons Attribution-ShareAlike 2.0 England & Wales licence.
OSS Watch is funded by the Joint Information Systems Committee.
