one more day is over @ ceylan's office

With the widespread of the internet, today there is many many open source projects. This means competition is now not only in between closed source proprietary projects, but also in between open source projects and closed source proprietary as well amongst the open source projects themselves. This requires projects to adhere a set of standards to stay alive – especially for those in their early incubation phases.

Having been in the OSS World throughout its prime time,  I have a good deal of observations as to how a project endures over time an become a success. ı would like to share this experiences as an executive summary here. Here it goes…

1. Your Project is Your Promise

It is always a good idea to mock up stuff for a developer. Learning by trial is one of the best way to improve one’s self. If you have a sparkling idea, start by writing in down and coding as soon as possible.

Develop your project any time you like. Invite your friends to join. Work / study all the way you like. This is only until you go public and make your statement.

Starting an OSS project is no different then taking on a new job – you make a promise, people will rely on you, so keep it!

2. Have a Clear Mission Statement and Defined Targets for Your project

This is something you should apply not only to your OSS project but almost everything in your life.

“Carpe diem” is a very striking phrase but does not work in professional world.

Define your project’s mission statement and keep it as short as possible. Outline the targets it has and try to satisfy those.

3. Ensure Your Project’s Life

You project is like your child. You should ensure a sustainable life for your project just like you prepare your child for the life. That means plan your time and devotion to your project. If you are not prepared to devote yourself, do not go public – otherwise this will only harm your credibility.

A good idea to find sponsors or work a financial model for your project. Your project needs you, you need time and time is money.

There is a lot of platforms that will provide the basic platform for free of charge. During your projects incubation, using one will save you hosting and other costs, also the tools they provide will give you the most effective distributed agile environment.

4. Have a Good Build System

Have an automatic build system that produces nightly snapshots. As your number contributors increase this will help your project have a better and agile distributed contribution system.
Prepare a “How to Build” page and enable your project to build without a complex build environment on an anonymous user’s system. This will increase anonymous contributions and conversion of anonymous contributors to committers in time.

5. Have a Schedule

OSS community usually follow the latest and the greatest. Thus, having a clear schedule that lists the dates and milestone / release deliverables is key to maintaining the interest from the community. Not to mention, try to adhere your schedule and inform of changes in timeline and / or features as soon as they are known to you.

6. Treat Your Community as Your Clients

A common mistake by OSS projects is sometimes they think they give away something for free or doing a great favour to their user base.

Do not forget, the motivation is “you should think of ‘free’ as in ‘free speech,’ not as in ‘free beer’”. This is as true for yourself as for your community. You DO get something in return, therefore treat your community as your clients.

7. Maintain Your Project

Keep an issue tracking system, an FAQ, a Quick Start Page and forum for the project. And do NOT just create the instruments like these ones just because the platform you are hosting will create them automagically for you. Use it!

You should view all this instruments as your channels to the community. A phone never answered creates nothing but frustration. The same goes for project instruments. Having these channels and actually using them properly will help improve the communication with your community.

Keep your issue tracking system live. Give “human” responses to acknowledge the need, assess the case and engage in early discussion as much possible as you can. It is also good idea to map issues that are confirmed to planned versions and milestones. This way your community knows that their submissions are valuable, and they know when to expect a return for their time and effort for the submission.

Forums are key to extend the community and gain popularity by helping out newbies. Unanswered questions will only make you loose potential new members. As always keeping one happy is 10 times easier to get a new one.

From postings in the forums and irrelevant, extract the common cases and mistakes. Compile an FAQ out of them, make it accessible and refer to it in the forums and issue tickets.

A project may also want to utilize channels like a News Page, a Blog by its contributers and IRC Channel, etc. The same rule applies though, you create the channel, it is your responsibility to keep it live and functional.

8. Try to Understand Your Community

Another common mistake is not paying attention to your community or not trying to understand what community requires.
A good example of that is, the attitude I have seen in some of the bug / enhancement submissions and forum postings. Once every while, we see developers or architects reply with some sort of “This is how it works and cannot change, PERIOD”.
A rather better approach is to try to understand what the change arise from, if it is worth to discuss the issue in detail with the community member(s).
If the request does not make sense, explain in detail and try to convince. An explanation like “Because it is more useful the way it is” is not giving enough details and terminative rather then collaborative.

9. Think Before You Code

It is a very good phrase that “Removing one existing line in the code is better then adding two.”
Adhere the common practises like DRY, Segmentize and Modularize, Use in-code Documentation, etc.
Always bear in mind that some new contributeos join projects and some leave in time. You should also ensure your code is maintainable and not reliant on specific people

10. Collaborate with Other OSS Projects and Encourage Downstream Projects

Do not try to solve all the problems yourself. “Car manufacturers do not produce nails and bolts.” Try to use what’s already available. Collaborate with the projects you are in relation with and help those evolve by identifying the missing bits and parts in them.

Similarly, encourage the projects make use of your projects and projects implementing complementary and extensional features to your projects. This is rather then being a threat another reason for a longer life to your project.

Well, I hope these observations help projects in their incubation as well as the ones enjoying their maturity.

Popularity: 100%