Maketing - interaction between developers

[This is part of Maketing blog posts series]

The most important asset for an open source project is without doubt its team of developers. While in a company the monthly income may define the level of loyalty, in open source is about passion in most of the cases.

As a leader of the project, it is critical to find the way to keep the developers motivated and inside the project for long time. There will be many coming in and many going out quickly, if you don't succeed to create a loyal core team which stays in for several good year, you are lost.

At some point, when the project is big, you cannot care about it alone. Physically, you will not be able to handle alone the management, development, advertising and community interaction. Remember that you have also a private life. Therefore you need experienced people to help others coming on board.

How to get new developers? Be open enough. Open enough means not to be very restrictive and not very open. Being very restrictive in accepting contributions induce the false impression that the high quality is protected. Well, indeed, no line of code means no bug as well as nothing to use. On the other hand, accepting everything tha is submitted it is going to create a jungle.

Finding the right solution is a matter of the application. In Kamailio/SER, the design allowed to split in components which are very independent in influencing the quality of the others. Core and main modules are been exigently taken care. New ideas and young code can be very easy just added as independent module, which, if not used has no impact to your running instance.

This modularity solves another potential issue with developers: coding conflicts. One problem may have many solutions, some developers can have different opinions about what is the best one. That is good, allow them to contribute separate modules and users will have the liberty to choose the one they like more.

What about keeping the developers loyal and passionate about the project? First, bring the developers to be part of project's evolution. Involve them in discussions beyond writing code: planning, management, new releases or events a.s.o., everyone will fill safer if they know what is going to happen.

Be aware of language barriers and mentalities. Everyone thinks in mother tongue, writing the thoughts in English may look odd or impolite sometimes. Try to understand beyond words, contact the person privately and figure out more details before judging to sentence.

Don't forget that human interaction make relations stronger. Whenever you have a chance to meet in person a developer, don't hesitate to go out for a drink. An open source project is an social entity.

When you are still leading the project and the other developers (which are not paid by you) contribute substantially more than you to project, then you are succeeded to set the development on the right track and have a self-sustainable evolution.