Episodic volunteering challenges can be broken down into:
- Attracting collaborators.
- Maximising the value of each contribution.
- Minimising collaboration overhead.
- Managing sustainability.
Attracting collaboratorsThe OSGeoLive distribution of Geospatial Open Source software has successfully attracted and sustained over 100 episodic volunteers - developers, packagers, documentors, translators and occasional sponsors. When considering the community management of this project, we summarised the key characteristics for success as:
- 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.
- 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 ok to expect something of 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.
found that projects which were successful at startup typically possessed:
- A clearly defined vision;
- Clear utility;
- And leaders who led by doing.
The projects which grew tended to:
- Attract larger user communities;
- Attract external developers, with half attracting a developer from another country;
- Provide fine-scaled task granularity, making it easier for people to contribute;
- And often attracted financial backing.
Software is a LiabilityA naive misconception prevalent in the software industry is that “owning more software is better”. It’s not. The amount of information in the world doubles every two years or so, and the amount of software created is innovating at a similar rate. This means that most software will be out-innovated within a year or two unless it is continually maintained.
Your software is not an asset, it is a liability needing to be updated, maintained, and integrated with other systems. It is technical debt, and you should try to own as little of it as possible.To ensure long term sustainability, it is increasingly important to spread the software maintenance cost, either by collaborating within an open source community, or by using a proprietary business model to aggregate license fees which are spent on a central product. Both models have their strengths and weaknesses, but for this essay we will focus on the open source model.
Cultivate your core teamSuccessful open source projects become large. With size comes complexity, which increases ramp up time and hinders casual contributions. The key strategies to address complexity are:
- Design modular systems, such that someone can quickly contribute to a specific task with trivial or minimal ramp-up effort.
- Cultivate and retain a core team who can spread ramp-up effort across multiple years of project involvement.
Episodic sponsorshipOpen source projects are vulnerable to episodic sponsorship. Organisations are often willing to pay a once off fee to add extra features, but are reluctant to pay for core project maintenance. Such investment strategies are destabilising for a project’s core team as sponsored contributors tend to leave when sponsorship ends, leaving behind a technical debt of extra software without the acquired knowledge or resources to maintain the software.
Proprietary vendors are better structured for handling episodic funding. They can legally restrict software use unless a fee is paid, enabling Software-as-a-Service business models. License fees are then aggregated and spent sustainably over time.
Loved to deathSimilarly, open source projects are susceptible to being “loved to death”. This happens when a project attracts an engaging user base without attracting matching contributions. The core team becomes overwhelmed leaving insufficient capacity to cover essential business-as-usual tasks.
Sponsoring organisations need to learn not to overload the community they depend upon. It is both bad karma and bad business. Successful open source projects have worked out how to apply a combination of:
- Politely saying NO to “gifts” of unsupported extra code and excessive requests for help;
- Help uses become contributors, either in kind or financially;
- Minimising the onboarding effort for both contributors and the project’s core team.
Government agencies and episodic contributionsGovernments deserve special mention. Governments all have a social mandate to provide services to their citizens. They are a prime candidate for engaging with the collaborative practices of open source software projects.
Drawing from these principles, governments around the world have been signing up to the Open Government Declaration which emphasises how openness and technology should be used to enable governments to be more collaborative, transparent, accountable, responsive, effective, innovative, and empowering of citizens. However, the episodic, fractured and short-term purchasing practices prevalent within government significantly undermines the collaborative potential between agencies and the communities that governments could be working with.
Let’s consider the key challenges.