Sustainability challenges with episodic contributions

Following on from an article by Ann Barcomb, I advised on managing the challenges of episodic contributions within open source projects.

Episodic volunteering challenges can be broken down into:

• Attracting collaborators.
• Maximising the value of each contribution.
• Minimising collaboration overhead.
• Managing sustainability.

Attracting collaborators

The 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.

A team from the University of Massachusetts researched the success characteristics from thousands of Open Source projects and came to similar conclusions. They found that projects which were successful during initiation typically possessed:

found that projects which were successful at startup typically possessed: 

1. A clearly defined vision;
2. Clear utility;
3. And leaders who led by doing.

The projects which grew tended to: 

4. Attract larger user communities;
5. Attract external developers, with half attracting a developer from another country;
6. Provide fine-scaled task granularity, making it easier for people to contribute;
7. And often attracted financial backing.

Software is a Liability

A 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 team

Successful 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:

1. Design modular systems, such that someone can quickly contribute to a specific task with trivial or minimal ramp-up effort.
2. Cultivate and retain a core team who can spread ramp-up effort across multiple years of project involvement.

Established collaborative projects will have addressed both these use cases.

Episodic sponsorship

Open 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 death

Similarly, 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:

1. Politely saying NO to “gifts” of unsupported extra code and excessive requests for help;
2. Help uses become contributors, either in kind or financially;
3. Minimising the onboarding effort for both contributors and the project’s core team. 

If a sponsoring organisation isn’t ready to act as a good community citizen, actively caring about the long term sustainability of the communities they depend upon, then they will probably have a disappointing open source experience. They will make self-centred, short term decisions, and won’t get the support they need when they most need it. They will likely be better off with proprietary software. (And the community would be better off without them.)

Government agencies and episodic contributions

Governments 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.

Sporadic spending

Government budgets are managed around a financial year, with budget approvals often not being achieved until well into the year and not spent until the last quarter of the year. As explained earlier, such episodic spending is significantly destabilising to the people and companies who provide open source software services and favours proprietary business models instead.

Chasing funds instead of collaborating

Open source communities typically become sustainable and scale by collaborating rather than by chasing funding. Things are different within government agencies who are typically motivated to address short term goals with internal resourcing or by securing funding. The team’s importance is determined by the size of budget secured, not by the level of collaboration. In fact, collaboration and sharing the credit typically weakens the importance and need for the agency’s team.

Fragmented spending

Government taxes are collected centrally then split between departments, then split between divisions, then split between teams, and so on, until a group is funded to address a requirement. This hierarchical breakdown of budgets is appropriate for funding physical tasks such as building roads or collecting garbage; however, for the implementation of generic software functionality, it is usually more efficient for agencies to collaboratively work on a common code base. Fragmented spending results in solving narrow, short term problems instead of thinking holistically and long term.

Big Bang Purchasing

One of government’s solution to fragmented spending is “Big Bang” purchasing. Recognising a need, sourcing budget, going through an elaborate purchasing process, and engaging a primary contractor to provide proprietary software to implement the requirements. This methodology also has significant limitations, prone to project overruns, outdated and inflexible requirements, monopolistic practices which prevent information sharing and more.

Conclusion

There is a symbiotic relationship between episodic contributors and a project’s core team. A core team is needed to attract a community and simplify the contribution process. The community provides valuable contributions to the project. Everyone benefits from the product created.