Presented at the GeoRabble forum.I’m about to share some insights into how to build a successful open source community.
Actually, a bit more than that - also how to tap into, and coordinate the expertise of hundreds of world leading developers, packagers, technical writers, project managers, marketers, translators and educators. And have all these people volunteer their time for free.
Because we have actually done all this - in building the OSGeo-Live project. At its core, OSGeo-Live is a DVD pre-configured with close to 50 geospatial Open Source applications, along with accompanying data and documentation, available in multiple languages. It is used in workshops and is handed out at conferences all around the world. I think I'm safe in claiming that OSGeo-Live has grown into a highly successful project, and that we have a learned a number of key lessons worth sharing.
We started OSGeo-Live in 2008 with the aim of building a DVD of geospatial open source which was to be handed out at the international conference for free and open source software for geospatial, or FOSS4G. The FOSS4G conference provides an attractive international marketing pipeline that we could offer projects. And as some of us were on the FOSS4G organising committee we were able to say, "if you get your application installed on OSGeo-Live, then we will hand this DVD out to all attendees at this highly targeted conference".We laid out a very clear vision of our target deliverable - namely a stable release of Open Source and accompanying marketing documentation. This clear and simple goal helped us many times by providing a framework to test the multitude of decisions that are inevitably encountered in such a project.The process of building our first version of OSGeo-Live involved installing geospatial applications on a base Ubuntu distribution. We followed install instructions, configured applications, resolved dependencies and conflicts, asked questions on email lists, and finally, after much hard work, we produced our first release for the 2008 FOSS4G conference. This was a very important first step as it showed that we had the commitment to follow through and deliver.
However, it also highlighted a number of our failings. We had followed a fully manual install process, so when the next Ubuntu release came out, we had to start the installation process again, from scratch. This was completely unsustainable. We needed to automate the install process, and we needed projects to show us how.But our first calls for help from projects was embarrassingly underwhelming. You see, the perceived learning curve for a developer to learn the intricacies of packaging was considered unacceptably high and volunteers were not stepping up.
To fix this, we got one of our packagers to write an example install script along with clear, step-by-step instructions. We then went back to developers with the message of "if you can spend a couple of hours writing a short install script which looks like this, then we will market your application on the OSGeo-Live DVD".
Small effort / High Value. And this worked! 28 projects packaged their applications for our 2.0 release.
We followed the same process with documentation, as our first round of documentation was mostly written by developers and as such was quite ... variable.
So the Australian Office of Spatial Data Management stepped up and sponsored one of LISAsoft's technical writers to create a template Project Overview, along with writing instructions. We then asked projects to write the documentation, and the technical writer followed up with documentation reviews, then all the documents went through our publishing pipeline in order to produce consistent, quality material. So by applying a template / write / review / publish process, we were able to achieve significant efficiencies by allowing experts to focus only on the bits they do best and thus reduce the cost of contributing.Another key to our success is that OSGeo-Live doesn't provide free rides for projects. If a project's community doesn't write installers and documentation, then they don't gain the marketing value of OSGeo-Live. This creates the business incentive for projects to help. It also frees up the core OSGeo-Live team to support a multitude of projects.
And by multitude, I mean 50 odd, and 70 odd volunteers, which becomes a project management challenge for a flat organisation structure like ours. To reduce swamping everyone with emails, each project nominates at a contact person to liaise between their project and OSGeo-Live. We use a wiki, issue tracker, email lists, and Google Doc spreadsheets and follow standard project management processes of managing a schedule and tracking status.
The simple statement of "if you want your application on the next release, it needs to be packaged this week" has been a motivating trigger for many of our volunteers to get started.
But the key motivator, along with the fun aspect of working on open source, is that there is a strong business case for each of our contributors to be involved.
- Application developers get valuable marketing, and get their documentation reviewed and translated.
- Our packagers' jobs are a lot easier because domain expects now take ownership of a large part of the packaging task.
- By just sponsoring documentation review, The Australian government's Office of Spatial Data Management gained a 5 to 1 return on investment when creating Project Overviews
- Translators gain quality source documentation and marketing pipeline.
- LISAsoft, who build geospatial systems using Open Source, have increased public acceptance of Open Source, by helping coordinate OSGeo-Live.
- For only the cost of printing, conference and workshop organisers impress delegates by giving them a free, comprehensive DVD of software.
- Likewise, the OSGeo Foundation is gets comprehensive, translated documentation of projects which can be put on its website.
So if I come back to my opening statement of "what is required to tap into, and coordinate the expertise of hundreds of world leading experts, and have them volunteer their time for free?" I guess I'd say:
- Start with a clear and compelling vision; inspiring enough that others want to adopt it and work to make it happen.
- This should be followed by a practical and believable commitment to deliver on the vision. Typically this is demonstrated by delivering a “Minimum Viable Product”.
- Be in need of help, preferably accepting small modular tasks with a low barrier to entry, and ideally something which each person is uniquely qualified to provide. If anyone could fix a widget, then maybe someone else will do it. But if you are one of a few people with the skills to do the fixing, then your gift of fixing is so much more valuable, and there is a stronger moral obligation for you to step up.
- Set a quality bar, and only accept contributions which achieve this level of quality.
- Ensure that every participant gets more out of the project than they put in.
- Avoid giving away free rides. If you are giving away something uniquely valuable; and it costs you time to provide that value for your volunteers; then it is okay to expect something from your volunteers if they wish to get something in return.
- Use templates and processes to facilitate domain experts working together.
- Reduce all barriers that may prevent people from contributing, in particular, by providing step-by-step instructions.
- Set a schedule and work to it.
- Talk with your community regularly, and promptly answer queries.
- And most of all, have fun while you are doing it. Because believe you me, it is hugely rewarding to share the team camaraderie involved in building something that is much bigger and better than you could possibly create by yourself.
