As an extension of the previous “From Zero to Sidekick” video, I have extended the environment to include: JBoss...
I’ve spent my last year at my current employer working with opensource projects, and trying to make them successful, and after one year I think I can have some ideas on common pitfalls that need to be avoided to make a project survive for some time. Here are some ideas that need to be worked on if you are on the Open Source.
Share the project goals, roadmap, vision,…
One of the most important topics regarding an open source project is that it needs to be clear what it is for and how it will grow over time. I’ve seen many Open Source projects where you can see in their home/docs what the project is about, but not what is the roadmap for the project.
If I were a company trying to make something on top of an Open Source project, I not only need to care on what the project does today, but what will do in the future, as this future might be very different than mine, and in that case I would not risk into that project.
One example of a project that I like how they show this is apiman
Having a strong community
This means that communication between the project committers and any contributor or user (community) has to be agile, and that needs to be paid very special attention.
I’ve seen some projects where questions lay around on the forums without answers forever. And of course, this can happen, but can not be the very majority of the questions, as it might look like as there is no interest in helping people adopt the project. Once a project has been adopted, people tend to contribute more, as they are in a necessity rather than on a inquiry.
An example project is Fabric8
Making the project look alive
A homepage that looks like we are still in the 20th century is not healthy. A project that releases a version every year, is not healthy. A project where forums are not active with questions and answers flowing around is not healthy.
Usually a project has daily contributions of code. The site, the docs also needs of this daily contributions. If the code is very active, but the site/docs are staled, then it will be difficult to adopt the project.
An example of this is Openshift
We are in the era of the web 3.0, very social, so we need to share information of the project as much as possible, share anything about the project that anybody mentions, make them show up in twitter, re-tweet, make interesting people follow it, blog about it, as there are people that are tendencies makers, so use them in favor of your project. I know people that have hundreds/thousands of followers in the IT industry, so make them help you if you can.
An example can be Wildfly
Demo, sample, show how to use, document, either through videos or blogs, …
I went to the website to one project I wanted to contribute, and documentation was awful, there where 4 videos from 2 years back, from a very old release, there where no demos that could be used, they had a very small amount of quickstarts of very little value, as they where very trivial. At the end, it took me more than half a year to be productive with the project. Recently, I have been following a project where they had very good video/tutorials showing the usage, a docker image to start using the project right away, a lot of meaningful demos using that docker images to demonstrate some meaningful use cases. I think that after a week I can use the project. Of course, I can not develop, but so far I understand all the concepts behind the project from a user perspective.
If I where leading an Open Source project, I would put every committer to spend one hour a week to write a blog, record a video or whatever could be done to make as much information available as possible. Usually forums are full of use cases, missing samples/scenarios/quickstarts that can be written in that one hour. A committer should be productive enough to have something valuable in that one hour.
Other options that I’ve seen are having an “Evangelist”. But so far, I tend to think that if a person is not contributor/committer of a project it is very difficult for him to be able to show how it works, or the business value, so if you want to go the Evangelist way, put him to learn the code 😀
An example can be Docker
Work with companies that want to adopt, so adopt a company to adopt your project
Companies are the best resourcing that you can have. If you can make a company adopt your project, and you work very closely with them to realize their use cases, they will probably spend on the project dedicating resources.
You need to have more than one company, or their use cases will become your use cases, so you need to stay focus on your goals. If you adopt a small amount of companies to support your project you’ll be very healthy.
Open Source can mean many things, but at the end, the most important one is that you need people to work with you, so you need to work for these people also. Yo need to attract them to you, as there are many open source projects to chose from, so why yours?
And of course, if you are a company using Open Source as the foundation of your projects, you need to invest and take all of these information into action. And once you have customers, contributors to your projects, you are devoted to them, so don’t fail them, as trust is very difficult to regain.
I’ve recorded a small demonstration video showing the OpenShift V2 cartridge: Cheers, Sebastian