So you feel ready to give back to the world some piece of software. Many of us do it. Such contributions keep the world of open source moving. But before you take a plunge think again! It may not be what you thought.
The code that you thought would be useful, did your job beautifully and one fine morning you thought of showcasing your achievement to the world. You picked one site that host open source projects and looked least intimidating — sourceforge, google, github… there are quite a few. There you go: select, upload, Done! You filled up some description to your code, shared your entry in social media.
Wait! you will probably find a mail on the very first day. If you thought it will be a mail praising your contribution, well get ready for the surprise – you get a nasty mail complaining poor documentation. Oh, yes! you thought — documentation are required. You left it out as that is not your strong point. Anyway you probably made one. Next you get is a bug report. Probably it was for a feature that is not supposed to be there. So you explained it. Before you would know you will find umpteen forks, bug reports, feature requests, criticism and no money.
If the above looks frustrating and ugly then you are welcome to the wonderful world of open source developers. Most open source developers get disheartened and abandon their projects. About 90% of open source projects die after one or two release. It should not be the case. When you think of an open source project understand the dynamics, plan and prepare well. For the user open-source is like any other software. They have their expectations, demands and own requirements. When you release a piece of software, it is no more a personal code. Plan for it!
Most open source projects get into trouble due to treating the code as the final deliverable. It is not! People use software to solve some problem. One need to accept that and address that requirement. Like any other software project, that work start with developing a clear scope document. List clearly what your code is expected to do and what it is not expected to do. Before you go any further, try and gather a team. A team that will complement different skills – documentation, packaging, testing, bug fixes, distribution, advertisement and such things. You may not get people for all these, but if you reach out to the world of open source you do get some help.
Next important thing is to document the features of your code. You may have developed an wonderful product but if that is not usable by others, it serves no purpose to humanity. Develop documentation to best of your ability. Preferably use a wiki and involve your team.
Third important aspect is to test your software. Get some volunteers, release alpha, beta versions to get the code right from many angles. Do not assume that every one will use your code in the same way. People come out with unexpected ways of using things and there we get most the bugs. You need to give serious effort to resolve the bugs quickly to keep pace with user expectation.
Forth, develop a thick skin. Some people will make adverse comments, no matter what. Remember, no one kicks a dead dog. Take the useful constructive criticism as opportunities for improvement. Leave the useless rants where they belong and move on.
Fifth, irritants are forks. Forks that undermine your work and try to grab the credit. Forks are a necessary irritant. Only way to fight it is to keep updating and releasing new upgrades. This is where a team comes handy. Original developers have the advantage of knowing their code well. The smart kid across the block has no idea to keep up with new releases.
In a world of open source the one who make most useful changes survive. So plan your release strategy. Plan for upgrades, accommodate new demands. At a certain point you also need to learn the art of relinquishing. When you find the utility of a particular has come down then learn to let it go. Let other newcomers take control of the code and fork it for new uses.