Creating Sustainable Strategy for Open Source Projects

When I first started leading Galasa over two years ago, there was only one question that I kept asking myself – how do I make this project sustainable for the long-term?

 

Open source is a unique way to develop software, predominantly because it is through the passion of developers, documentation writers, designers, architects, and leaders that volunteer their time to spend creating something they believe in. This can create something extraordinary and industry-changing like Kubernetes, Zowe, Linux, and the vast array of projects that are used across the IT industry to keep the world running. However, the downside is that unless you have a continuous stream of volunteers, these open source projects can suffer and find it difficult to continue.

 

There is often a passion and driving force behind those that maintain open source projects that keep the community alive, and that can be seen through webinars, blogs, conference presentations, awards, YouTube videos, and more. However, if this isn’t curated and thought through, especially when the project is small, it can be hard to gain the publicity and the extra support that you might need. For example, if someone new picked up the project to use it for the first time and they had nobody to contact for help when they got stuck, it’s unlikely they’ll continue using it.

 

When I took on Galasa with the rest of the brilliant maintainers and committers, it was clear we needed some guiding principles with the activities we were going after as a group. What would help the project survive for the long term? What can the maintainers do to continue attracting new users and developers? What is the strategy?

 

Firstly, strategy is a concept that has been poured over and written about over centuries. However, for this, I’ve used the definition that strategy is a plan of action designed to achieve a long-term or overall aim. So, the first thing for us to do was define the mission and vision – what was Galasa here to achieve?

 

The mission was defined as the following: to allow customers to deliver software with confidence by simplifying and encouraging automated integration testing to help Mainframe modernisation within Hybrid Cloud environments and increase the reliability of repeatable software releases. Yes, it was long and wordy, but it best fit what the project was about, to make deploying software on the Mainframe easier and more reliable.

 

Then, once we’d defined the overall aim of the project, it was time to consider what were the long-term goals that we were trying to achieve. The guiding principles by which when we are choosing to do something to benefit the project, did it fit into the following aims?

 

1.     Grow the number of users and companies utilising Galasa.

2.     Grow the number of individual contributors on GitHub.

3.     Deliver version 1, user requirements, and features for Galasa.

 

These may seem far reaching and not very SMART (specific, measurable, achievable, realistic, and timebound), well, that was the point. If we created goals that were too difficult to obtain, everyone may lose interest and find it demotivating. On the other hand, if the goals were too specific, and everyone was volunteering time, then they may find the pressure of holding to those goals too much and they would not continue.

 

In reality, it has been difficult to continue all three of these goals at the same time – sometimes it’s more important to prioritise the build pipeline and creation of a better documentation experience, than it is to blog and make videos about the project. However, they have provided a good steering guide for the maintainers to consider what they are focusing on.

 

The most important thing about creating a good strategy is the ability to remain consistent and reliable in delivering in small steps towards the overall aim. The journey for Galasa remains bumpy as we enter our third year in the open, however it’s the love and passion for creating something that will be used to make software engineers and enterprise level applications more resilient for the long term keeps us motivated.

 

How have you created strategy for open source projects? Do you agree with what I’ve laid out, or have you done things differently? I’d love to hear your experiences.

Popular posts from this blog

THE COMPLEX LANDSCAPE OF PRODUCT MANAGEMENT

SKILLS FOR LIFE CAMPAIGN ADVERT

Skills for Life Campaign Launch