I am working with Open Source software for more than 6 years and since 2014 I am building my business based entirely on Sylius. I have always loved programming but very early in my career I realized that what keeps me going is building new things in general, not only through coding. I like coming up with new crazy ideas and with the help of others – making them a reality. But even with that entrepreneurial spirit, it took me some time to abandon the typical programmer mindset – being too focused on the code alone, forgetting that there is a product in my GitHub repository.
Yes, the fact that you give away software for free & develop it with a community does not change the fact that the end-result is supposed to target a specific audience, which has a specific problem. There are some channels, through which people can learn about it and also there is competition. While Open Source is all about collaboration, you still have competitors.
I have been using Lean Canvas for iterating on the business model of the Sylius company for a while. All services & products have dedicated Lean Canvas documents, which identify the fundamental aspects of our operations. That being said, our main product – Sylius eCommerce Framework is completely free and does not generate revenue directly. I am definitely a planner-type of a person, which means I like to have everything well-defined, like areas of focus, mind-maps, my GTD, etc. At the same time I hate long, boring documents, which are never read nor updated. So I adapted the Lean Canvas template to reflect the reality of an Open Source project. This way, Open Source Canvas was born.
I got this idea at SymfonyCon 2016 in Berlin and added it as an extra slide at the end of my presentation. It got some interest from the audience and since then I showed it at couple other conferences. I constantly use it to iterate on what Sylius should be and today I’d like to share this concept with the Open Source community, which hopefully will help fellow maintainers to make better Open Source products.
Obviously, Sylius being a full-featured eCommerce Framework is a bit complicated example of an Open Source project. So for the purpose of this blog post I decided to use another interesting project – Imagine, a PHP library for manipulating images. It was created by Bulat Shakirzyanov (avalanche123) and has been widely used (8.5M+ installs) by developers to resize, crop and optimize images. Keep in mind that I did not consult the author – these are my post-factum assumptions and observations just to help you understand concepts behind the Open Source Canvas.
The first step is to define the problem you are about to solve with the potential new library. Most of the time, developers create new Open Source packages to solve a problem they encountered in their current project. Very often the solution is implemented in a specific application and then extracted to a standalone Git repository. Open Source Canvas can help to make a decision whether to release it publicly or not. Also, it serves as a framework for defining the vision for the library.
In this step, you should pin down the top 1-3 problems that your concept is solving. This will also let you focus on the most important features and avoid being distracted by all the “cool functionality that only 3% of users will benefit from”. In the case of Imagine, I defined these as general “manipulating images” and more specific problems like “generating thumbnails” and “watermarking images”. You should really focus on understanding and clarifying the problem you encountered, so that further evaluations make sense. Then you can also have a look at the alternative solutions and define the differences between them and your approach. Step two will help you with that.
Do not reinvent the wheel. Really, you have just one life on this amazing planet so use your time wisely. You can’t be the only person who had this problem and there are perhaps hundreds or thousands of people working on the solution already. I know, you probably like to have the things your way and you noticed plenty of improvements to the libraries in your research. Implementing these would be easy but making it a complete, well-organized and popular solution is far more difficult than just programming. Focus only on the things you can do better and reuse what others provide, that’s the spirit of Open Source. I hope this Canvas will help you define the unique value that your product can provide or make you comfortable with the decision to contribute instead of reinventing.
Research online for the existing solutions. Of course, you just Google it, then check package repositories (like Packagist for PHP or NPM for JS) and maybe tweet to get some recommendations from your network. You should not limit your search to libraries written in the programming language of your choice – please consider API-based solutions as well, which can be integrated in any app. What is more, PHP for example, is well known for porting libraries from other communities and very often these ports are as good or even better than originals.
Best case scenario is that you find a suitable solution, use it, save time & maybe contribute back. In case you do not find a project that solves the problems, you can get a lot of inspiration from others and make a better solution. In case of Imagine, I found various solutions and outlined the reasons why I think Imagine is different:
- Image manipulation with GD – Provides only function-based API, which does not allow for easy testing or implementing different adapters;
- WideImage – Uses old PHP version (5.2) and is not maintained anymore – this is crucial. Check last commit’s date and releases frequency before investing time into any library;
- Intervention Image – This one looks like a viable alternative. Imagine started in ~2011, while this library is from ~2013. I can still point out an important difference: Intervention is more focused on the Laravel framework, which usually prefers a bit different coding style than Symfony.
Step number three is the real show time because you need to define how you will solve the problems. I would keep this part 3-4 sentences long and focus on the fundamentals of your idea. Also, you should illustrate what is unique about it. In case of imagine, I outlined the 3 main concepts behind the library:
- Object Oriented API, using the latest features of PHP language;
- Tested & testable architecture;
- System of adapters for lower-level components that do the actual image processing: GD & Imagick.
Defining the Unique Value Proposition is a really important step. If you can’t easily explain your product with 1-2 sentences, then maybe it is not unique enough. Does it really differ from existing solutions except the facts that you created it yourself and used your preferred naming for classes and methods? I took the text directly from the README and I think it perfectly describes what Imagine is about.
PHP 5.6+ Image Manipulation Library
It contains crucial information about the product: it uses latest PHP features and takes care of image manipulation. Simple and I remember it was enough for me to get interested when looking for such solution back in its early days.
Now that we have identified the problem, checked for existing solutions and also defined our alternative proposal, we should consider what kind of developers & businesses would benefit from our project. It is a product, remember? It has potential customers. Yeah, they are not paying customers but besides that they behave exactly the same.
They will have positive/negative feedback. What is more, they will evaluate your solution against alternatives and they will generally go through a very standard decision making process. Except the price factor because it is obviously free. Take some time to describe the type of a developer that would be a potential user of your library. The more you know about them, the easier it will become to get more downloads, contributors and spread the rumor because you will know where to promote it and what is your target audience in general. In case of Imagine, I narrowed down the characteristic to the following points:
- Group of developers according to the language (PHP);
- What coding style do they like;
- What frameworks do they use;
- What other solutions they may have used in the past;
- Where do they hang out and discuss this issue.
There are other traits you could include here, I encourage you to check our the concept of Customer Persona. It can be applied here as well.
It is also worth to consider what kind of businesses will use the software. Image manipulation is quite popular, but our problems are relatively simple and PHP narrows down the company profile to a much more specific segment than just “Everyone”. Some of the things worth considering when filling this box:
- Is it manufacturing, selling goods or services, do they operate offline, online or both;
- What kind of engineers do they have;
- Company size;
- Where can you reach them.
Many developers use & contribute to the Open Source software but it is usually their employers who pay for their development time. So to get some support from them, they need to get a greenlight from the management. Let’s say you want to organize an offline hack-day and that requires more resources than you have available. It is good to know who you are looking for when searching for some kind of a sponsorship, etc.
This is crucial step and maybe one of the most important in the process of filling an Open Source Canvas. No matter how good your code is, it won’t get popular if people don’t know it and there is no platform for the community to grow on. Depending on the audience (which you defined already) and size of the project you may consider the following channels:
- GitHub/Bitbucket Repository
- Social Media (Twitter, maybe Facebook or LinkedIn)
- Chats (Slack Community)
- IRC Channels (old-school cool, but I’d go for a Slack Community)
In this step you need to consider both where your existing community members will collaborate but also where you can meet / discuss with potential new users.
The day you come up with an idea for Open Source library will be super exciting and you will have tons of motivation to pursue it. Also when you actually code it – that will be another boost but believe me, you cannot run solely on the initial excitement because maintaining an Open Source project can be a lot of work and is not always that easy. Defining what kind of benefits you get from releasing this specific piece of code to the public will help you decide how much time & resources you dedicate to it and also maybe you discover new ways to monetize the work you do. These can be various things:
- Getting more renown in the community;
- Higher chance of being accepted as a speaker at conferences;
- Help with testing on various OS/environments;
- Bug fixes / features suggestions;
- More leads -> higher hourly rates (if you are a freelancer);
- Something unique in your CV when you will be looking for a new job;
- Opportunities to network with other maintainers who can be truly inspiring people.
- Many more!
Core Activities & Costs
As you can see, doing Open Source can bring you a lot of benefits but it is good to also realize how much work it can require. Sometimes it is also money that needs to be invested to get expected results. For instance, when you decide to launch a custom website or buy a domain. Here you can also define how many hours per week you can invest in the project maintenance. If you are an employee and your company does not have Open Source culture, then it will most likely be your free time. But for a freelancer, maintaining a popular Open Source library should be part of the marketing strategy so it will be easier to dedicate more time to it.
By defining core activities you also identify what kind of things need to be done for your project to operate successfully and also makes it easier to split these tasks among several roles. Seeking co-maintainers or active contributors who will help you with these responsibilities is essential. This box should contain everything: from the very basics like reproducing bugs from reports, implementing new features, writing documentation to more project-specific things, like ensuring compatibility with C extensions from PHP in case of Imagine library.
“You can’t improve if you do not measure” and “not everything that counts can be counted, and not everything that can be counted counts”. OK, that’s enough of smart quotes for one paragraph but both are true and apply to the Open Source Canvas rules as well. Here you should identify the metrics that will tell you whether the project is going in the good direction. Obvious example would be downloads count, which you can read from most of the package manager’s websites. In case of PHP that is Packagist.org. More downloads means more users and higher impact of your project in the ecosystem.
It would be also interesting to check the correlation between users & contributors. If the percent of contributing users goes down or does not really grow together with number of downloads, then perhaps you should invest a bit more in Contributing Guide or shoot a couple of tweets and ask for help. Keep in mind two more things: Statistics which are not analyzed and acted on are only an unnecessary cost. You could schedule a regular (every week/month) review in your calendar/GTD system. Also, focus on 3-5 metrics that are most significant and automate the measurements & analysis as much as possible. Even a simple Excel with a couple of formulas plus getting the data from an API can save you a lot of manual research and give an insight into your project’s progress.
That’s it, it should take you about 15-30 minutes to fill the Open Source Canvas and as a result you get a solid foundation for defining the vision & strategy of your next library, on a single piece of paper. Keep in mind it is an ongoing process, hence the date & number of the iteration in the top-right corner of the document.
Give it a try!
Open Source Canvas is available as a Google Docs template. Open it via this link & then use “File” > “Make a copy” to create your own canvas.
I could not find the author of the original Google Docs template I adapted, but at least I will share the link to the original: https://docs.google.com/presentation/d/11qdgI8R80F4cig97mygnvjREF6yxG_Ifmxsn5QVjGRY/edit.
In the spirit of the Lean philosophy, I am releasing this as an MVP and will iterate on it based on your feedback. If you have some thoughts about the concept, please let me know in the comments section below this post or hit me up at Twitter: twitter.com/pjedrzejewski. I’d also greatly appreciate if you share this post with your fellow developers and spread the message. #OpenSourceCanvas sounds like a good idea for a hashtag! 🙂