Monday, 16 September 2013

OpenSource and the Social Contract

With FOSS4G around the corner many OSGeo projects are putting on a final push to get a release out.
And of course OSGeoLive which will be launched at FOSS4G September 17th. QuantumGIS is getting close to a 2.0 release and so on ...

Social Contract

If you are following any of the project mailing lists there is a lot of social pressure to pitch in and help during this time. This is the open source "social contract" in action, and it can be a bit confusing if you are not quite sure what is expected, or the time frames involved.

Here is an example email I sent to the GeoServer Users List:
Reminder: This is the *last week* for release candidate testing.
If you have not already done so please take an hour this week to download the GeoServer 2.4 Release Candidate and try it out in your test or production environment.
Reminder that GeoServer, like many other open source projects, is not linux and cannot rely sheer numbers to test an a wide range of platforms, and more importantly with a wide range of datasets. This is where you come in!
Open source is in spirit a social contract. We have a number of organisations holding up their end of the bargain with great new functionality.  This is where the project really depends on geoserver-users for a few critical weeks of testing.
The announcement was clear about this expectation, let me be more blunt - if you are asking for help this week the immediate response should be: How is the release candidate working for you?
If it helps to make it personal, since Andrea made this release, think of this as your chance to thank him for all his hard work :)
If you need to seek approval from management to take part, please send any questions about what is going on to myself (or any of the project steering committee).
We are not normally so blunt on the social contract part of this, but after last weeks response I am going to assume many here are new to open source.
This is not a week of free support, it is your chance to shine as a member of this community.
Communication between the developers, participating organisations, and users of a project are a key factor we look for during OSGeo incubation. We really want to see evidence that these parties are able to coordinate around activities such a making a new release.

Why the Pressure?

So why the social pressure to help out with testing?

Advocates of open source often point out the amazing response time users can experience when submitting a bug. The flip side is the amazing time-savings a developer can experience when submitting a fix that may (or may not) work, and getting verification promptly.

From a software development standpoint, a key enabler of Open Source is the "free testing" which motivates the "release early release often" mantra of open source development.

Large Projects

Large projects, such as Linux, can get away with "release early release often" and expect very quick feedback from a wide range of operating environments. This can result in excellent test coverage simply by virtue of the vast number of users trying out the software.

If you are experienced working with these projects you may be accustomed to holding back from updating, and perhaps not participating in testing at all. The logic being that you should not waste your time until everyone else has finished testing (and the bugs have been worked out).

Small Projects

Smaller projects, such as everything provided by OSGeo, cannot depend on a vast community to test a range of operating environments.  Indeed with our focus on mapping and geospatial data, it is perhaps more important that the software is tested against a range of datasets worldwide.

In this scenario, not participating in testing can work against you. With a lower volume of users it is unlikely that one of the developers (or another user) is going to accidentally cover your needs. If you do not try out new functionality when given the opportunity you are stuck finding integration issues after the developers have moved on.

The developers know they have a smaller community to work with, and only really push for feedback:
  • When a new feature is available in a nightly build. This is a great time to help as developers often have budget to look into issues or review your patch. 
  • When a release candidate is available, in order to help determine what functionality is stable enough to be included in the release.
So if you are working with our OSGeo projects, and not taking part in testing you are missing an opportunity to ensure this software will work for you.


As indicated above, being sensitive to the project release cycle, can help provide context for all the tweets, blog posts and emails leading up to each release.

Keep in mind that positive feedback is very valuable. Twitter has been great the last couple of GeoTools releases in letting me know the project builds on exotic environments such as Windows or Java 7.
For our OSGeo projects, just before FOSS4G is a great time to pitch in and lend a hand. No amount of help is too small!
Post a Comment