Open source projects are very advantageous for the technology world: they create tools that are fit to real developer needs, they save time and money and they are reliable because they are exposed to and tested by wide audiences. They also have advantages for the open source community: they encourage collaboration and distribution and they attract new talents.

Just as important, open source projects are valuable to the developers themselves. Open source contributors have a chance to develop their technical abilities and they have an opportunity to stand out as talents. Outstanding developers enjoy a positive reputation in the software world. This is empowering on a personal level, and can also lead to better job opportunities.

Therefore, it’s no surprise many developers aspire to take part in the open source community. If you are looking to start and manage your own open source project, are looking for advice about the open source project you already started, or even just interested in learning more about open source projects, this blog post is for you.

How to Contribute to Open Source Projects

There are many ways to contribute to open source. Code, obviously, is the first way that comes to mind. But you can leave a footprint in many other ways. A very important way to contribute is to help with build management, QA and documenting. This is relevant for mature projects, and can help release software teams burdens. You can also provide feedback and ideas. These are crucial for projects in early and mid-life stages. Feedback helps polish new projects and make them mature. It also helps to avoid stagnation in later stages.

Another way to contribute is by writing educational content, like blog posts. One of the important ways that BlazeMeter contributes to the open source community, for example, is by writing multiple blog posts each week about open source load and API testing tools, like Apache JMeter™. The content is free and open and can be used by anyone. Thus, it is in fact a contribution to the Open Source community.

Finally, you can ask and answer questions on forums like Stack Overflow. Questions become a form of feedback and the answers become a very important and valuable source of information about specific use cases.

The GitHub Graveyard

Open source projects can be professional if you treat them as professional. Just look at projects like Jenkins or JMeter. But the largest open source graveyard for unprofessional open source projects is GitHub. GitHub reports having approximately 20 million open repositories, but two thirds aren’t active or popular. Just because a code is on public source doesn’t make it an open source project.

The Second Wave of Open Source Contributors

We are seeing an interesting phenomenon now - people who want to contribute to open source, even if they don’t understand it deeply. This is opposed to the first wave of contributors, who wanted to understand the technology first, and then contribute.

These second wave contributors need guidance, but they don’t always receive it. When they ask in the community how to start, they are answered to fix some simple bugs. But because they don’t understand, they offer irrelevant solutions. This can frustrate everyone. If they had proper guidance, the whole open source community could grow.

Open Source is Just Like a Startup Business

Anytime you are stuck, aren’t sure or just thinking about your next step, remember that running an open source project is like running a startup - they both have the same lifecycle as well as the same activities and threats (I will elaborate more later on). So think - what would you do if this were a startup? The only difference, maybe, is that while startups have exits, it’s unclear if open source projects do.

How to Start Your Open Source Project

This might seem counter-intuitive, but don’t start an open source project right away. Rather, join an existing community. Start a new project only if you’re sure you’re not competing, because fragmenting the community doesn’t help. You’re also too small to compete. There is great potential in joining. But what is it?

Think like a startup - where is my differentiating factor? It could be for example a plugin or a knowledge base for an existing project. Find a real gap and fill it. Sometimes you might think of something cool that excites you and start your project around it. But if it doesn’t match the market’s needs, it won’t be adopted.

If you’re having trouble finding a need, think of needs from your day job. Most projects start from primary job needs. That’s how you know the problem is real.

Prepare for major investments of your time and efforts. Growing an open source project takes years. You won’t take off like a rocket, even though we all hope we will. Instead, you will need to invest lots of time in establishing the audience and growing your project. This can be frustrating, just like with a startup.

Early Priorities

If you really want to grow your project, you have to step away from your source code and focus on marketing. You already have the code because you already solved the problem. Now, you should distribute your project and spread the word.

A very important way to market is by documenting. Creating content, and especially valuable content, will make Google index it and get your project up on the first page when someone hits the same problems you do. So write documents, blog posts and articles, and answer questions on Stack Overflow.

Another thing you shouldn’t overlook is the UX. If someone comes to your project and it’s ugly and not intuitive, chances of them spreading the word to their friends are slim. So invest in becoming attractive.

Create support channels. Support is very important and you need to have several channels for users. Response time on these channels should be quick, patient and friendly, and feedback should be collected to improve the project. Comments about bugs and missing features will help you survive, adapt and evolve.

Finally, try not to put too much effort in the process overhead. Just like startups, don’t focus on bureaucratic processes but rather on nearest term growth needs.

Managing Growth

After establishing the infrastructure for distributing your project, it’s time to grow it. Start by attracting contributors. As mentioned earlier, there are different kinds of contributors and you need all of them.

When you have contributors, value them and invest in them. Be attentive to them, stimulate them and be friendly to them. Remember they aren’t passively consuming your project - they are contributing to it and amplifying it. Contributors are like a startup’s partners.

Improve your project’s infrastructure. If you started out on a hosted website like GitHub, and some point you will need to upgrade to a fully-controlled VPS in AWS or other hosting provider. These provide a more solid looking project page, showing you are a grown up.

Give control away carefully. It’s your project, but you can’t be a dictator or stay the king or queen forever. If you do, your project will hit a glass ceiling because you will never attract enough contributors. As a result, the project won’t survive. This is a typical founder’s trap - so don’t be afraid to give away control, and then retire.

Listen to possible second-breath ideas. You will hit stagnation. To move out of it, listen to all the ideas about your project, read all the blog posts and listen to the field feedback. These will help you understand how to transform and reach the second-breath stage. Otherwise, your project could dwindle down.

Don’t limit commercial companies who use your project. This is an important way for growing your projects. Otherwise, only enthusiasts will use it, and your audience will remain small.

Monetization

If your project becomes popular enough, money questions will start to arise. But don’t be greedy, be flexible and concentrate on growth. If a sponsorship or partnership can help you grow and expand our audience and improve your reputation, go for it, no matter how much or little they pay you.

In fact, you probably won’t receive a significant amount of money unless you give up a significant amount of control, just like in a startup. Don’t. Instead, be open-minded for partnerships. Your outcome might be indirect, like a better workplace or the feeling of being successful.

Sponsorship or ad money can help with small expenses like web hosting and SSL certificate needs. You might also get some money for yourself. But don’t expect to retire on that money.

Don’t ask for donations. It’s small money and a huge dent in your reputation. Startups don’t ask for donations and neither should you.

Threats & Solutions

Remember that everything ends and that-most startups don’t reach even the medium stage. This happens partially because of the lack of effort and intention by the founders, and partially because the project misses the market needs. Here are some things to look out for and what you can do:

Changes in the founder’s primary job or a loss of interest. This is the largest death factor for open source projects. If you don’t have contributors at this stage and you don’t have any more time or interest to put in improving your project, then your project will silently die. Don’t be afraid of this, sometimes this situation is ok. You need to live your life.

Prepare for a long-term investment and keep optimistic to get some traction. However, if you see low adoption over time, maybe it’s time to retire. In this case, keep your project as open source, stop investing and offer the adoption to somebody else.

You can put an announcement on the project website stating that the project is open for adoption. This is how I started managing, developing and evolving the Jenkins Performance Plugin. At some point I will also retire, and I will give back the project by offering it up to adoption. Remember, we have limited resources, so it’s ok to transfer the ownership.

When you’re too excited about your coding and making changes, you might introduce rough changes or you might make your project unstable or incompatible with previous versions. This will drive people away, while saying they can’t use technology that evolves like that. So listen to feedback and be careful about the changes you make.

Slowly declining due to feature stagnation. If you aren’t able to ascent to the second breath, your project will stagnate. The world is changing and if your project doesn’t fit, new alternatives will emerge. So listen to second-breath ideas, as detailed above.

Since open source is a lot about people and enthusiasm, social behaviour is important. Take note of how you answer people. Be patient when others who are less experienced ask a question that was asked thousands of times. Take note of how you treat your contributors when they offer something that is opposite to what you think. If you think the project is 100% yours and act like a dictator, instead of getting excited about suggestions; if you call people stupid if they are misusing your software, or if you treat people negatively, your project will get killed really fast. Think like a startup, would you act like that to your customers?

Contributing to an open source project and improving open source tools is satisfying, and helpful, so make open source contribution a regular part of your work.

You can learn open source JMeter for free through our JMeter academy.

Click here to subscribe to our newsletter.

To check out BlazeMeter, which enhances JMeter, request a demo or just put your URL or JMX file in the box below, and your test will start in minutes.