Sharing my challenges and lessons learned in building an open source product

There is an important reason why I decided to build my software product in open source. I feel it is very valuable to have a group of developers work on your project together - one of the most valuable aspects of Open Source. On the other hand it makes a project much more challenging. Let me tell you about my experiences starting an open source project, and how I repeatedly failed to make it work.

Some background on open source principles

Open Source projects allow you to learn from other developers working on the project, and share the lessons learned back with each other because of the use of open code. From the perspective of a developer, contribution is a great way to practice your coding skills and to work on an existing project, rather than having to start from scratch. Learning collaboratively is, therefore, probably the greatest benefit of working on open source projects.

You see open source project a lot these days which, in my opinion, is a very positive thing. Rather than keeping everything to yourself as a developer and business owner it is a way to openly collaborate and share knowledge. A great example is Microsoft, who came around to contribute open source code, and not just consume the software. As their CTO puts it: "If you're going to be a vendor of open source...you need to be part of it to understand it."

The challenge of starting an open source project

There are a few challenges to open source for businesses once they run, but to get started with the project and build a product, grow a community, this is the tough part that comes first.

Any software development project has its own technical and organisational challenges. For open source the element of collaboration comes in with a group that is, desirably, bigger than your own core team and who work mostly remote. How do you set up your project to have an optimal collaboration within your community?

As open source is all about collaborative learning, I'd like to share some of my own learnings on this part from starting my own open source project called Offcourse. You are going to read about what did not work well in the project.

Learnings from my own open source project

A bit of background on the project first: Offcourse is an online platform for open, personalized learning to develop 21st Century Skills, such as design, entrepreneurship and programming. It is important to note that not only the code within the project, but also the content is open source. This makes collaboration even more challenging for this project than it is for other open source projects.

The right focus at the right phase of the project, is what I now see was needed, but it took me some time to get there. Four main things I learned along the way:

1. There's a time for everything.

From the beginning there was too much focus on the product, and getting a minimal viable product out. This probably has to do with the fact that I'm a developer myself and I was approaching the project from my own developer perspective and ambitions, not as an entrepreneur. So I decided to involve external people: students who wanted to learn how to code and could contribute, but also consultants.

What did not work well in this case was that the timing wasn't right yet to get consultants in. There was no proof of concept yet and so we had no point to start from. Most successful Open Source projects first have a proof of concept before they start building their community.

2. Optimize for developer happiness and so create the lowest treshold possible for people to contribute.

If you really want to become an open source community you need to optimize for the developer happiness. **Building a community requires a lot of work at the beginning and we had limited human resources to set up the structure for collaborative development. We couldn't facilitate the developers enough with structure, time and tools to find their way in the project. Tools like documentation on contribution and collaboration principles, a style guide etc. This created a barrier for people to contribute.

One other thing that caused a barrier for contribution was my decision to build the Offcourse platform in Clojure script. This decision was based on the fact that it is a small and very enthusiastic community and, therefore, in my belief, could be a great community to embrace the project. Also, Clojure script was a language that was very up andere coming at that moment. This turned out to be somewhat of a mistake afterwards, because the language became a barrier for developers to contribute.

3. Create excitement around the project.

This brings me to the fourth learning in this great adventure, which is about creating excitement among the audience. There are many open source projects out there, why would a developer want to work on Offcourse rather than any other open source project? A first version of the Offcourse platform is live now and I've built a diverse, but very local and small community around it. Now is time to reach a broader community by clearly defining who we are.

So as you can tell from the above, I'm not there yet. I believe in building a community of people who share the same believes, rather than any shared background, nationality or whatsoever. For the Offcourse project specifically this means the community should consist of people who have a strong sense of ownership and commitment and who believe in the same idea of learning.

I'd like to get in contact with people who have experience with building an open source community or working with open source in general. Leave a comment or send me a message!

You can find the Offcourse platform at : Offcourse.io