10 golden rules for starting with open source - Blog - Open Source - schlitt.info

schlitt.info - php, photography and private stuff

10 golden rules for starting with open source

Are you new to open source? Or if not, do you still remember, what it was like, as you first started with open source? I recently tried to remember these days... back in 2001, when I started playing around with PEAR and shortly after that started to work on my own packages for PEAR...

I'm quite sure, I violated at least 9 of the 10 rules I will try to write down here, which you should know about and which you should take to the heart, if you want to be a part of the open source community. At least, you should keep these rules in mind, if you want to join the PHP community, but I am quite sure, it applies to any other community out there, too.

If you want to start with open source development right now, be sure to read through the following rules, before you act any further! I'm sure, you have lots and lots of great ideas in mind and can not wait to talk them out loud and start realizing them. But, take a deep breath first and read the following rules, think about them, take them to your heart and then start over and rethink them again...

1. Stick to your level of Karma

Open source is not a democracy. You have heard something different? This is wrong. Always keep in mind: Open source is not a democracy. Every developer has a certain (unexpressed and inexpressible) level of Karma, which allows him to decide (or even dictate) things and to make use of certain infrastructures of the community (like their version control system, their servers,...). Think of Karma like your points level in a role playing game. The more levels you played and the more riddles you solved, the higher your Karma level grows. But beware, it may also drop, if you act improperly.

That said, if you are new to a community, your Karma level is 0, per default. You should always keep that in mind. So, what is this all about Karma and stuff? Karma basically means the trust the community has in you. It is not possible to measure Karma in a number or even to guess it, because there are so many factors influencing your Karma and your Karma level is different for every individual of the community. For example your level of technical experience usually highly influences your Karma: The more you know about the subject your project is about and about the technical environment, the higher your Karma will grow. Another factor is the amount of work you spent for the project: If you're a member of the project for ages and spent thousands of hours of work during that time, your Karma will probably be high, too.

There are many more factors, which influence the Karma of an open source developer, as you will experience in the following weeks and months. What you basically should remember is: If you are new to the community your Karma level is (at least near to) 0. To raise your Karma you need to show the community that you are trustworthy. Do so by simply sticking to the following 9 rules.

2. Information is Karma

The first thing you might probably want to do is asking a question or proposing a cool idea to the community. Most probably, you will do so on a mailing list, which is the most common communication channel in the open source world. Keep your self back from that at first! People get annoyed really fast, if you ask something which is obvious in there eyes or if you propose and idea / ask a question, which has been proposed / asked by others before (especially if this already happened multiple times).

So, what should you actually do before posting a question? Search for information! Try Google, the projects website, the mailing list archives, the projects blog planet and any resource you could ever imagine. Don't perform just 1 search, but refine your search to see, if there is really nothing related to your question. There isn't? Try searching some more! There really isn't? OK, then go ahead and write your post. But be sure to read the following 8 rules before you do so!

And what to do, if you have an idea? Go the same way you should do for questions! See, if anyone else already had the same or a similar idea. You can't find anything? Really sure? The go on with researching about the topic. Don't just write something like "Wouldn't it be cool to..." or "I had the idea, to...". Research the topic you want to talk about pedantically. How do other projects (possibly in other languages or on other operating systems) solve the issue? Is there anything similar out there? Think about other users needs. Is this something especially for you? Then start writing a so called proposal. Choose a descriptive subject for your post (not just "I have an idea" or similar). Start writing a specification: What is your problem? What is your idea to solve it? How does that fit into the project? What is necessary to do it? Be verbose with all this! In most cases other people have a completely different perspective on the whole situation.

3. Getting used to it

A very important point before you start being a "contributor" is to get used to what you are working with and what you are talking about. You probably never used some of the tools that are commonly used in the project or it uses different tools than those that you are used to. Get used to those tools and more important, get used to the project itself. Knowing all the processes that are implemented within your community is an important point. Being used to the tools they use is even more important.

One of these important tools is GNU patch, a tool to apply differences (commonly called a "diff") to an existing version of code. Generating a patch is commonly done with the GNU tool diff. If you want to supply a patch for some code, you will probably need this tool. A lot of projects use so called "version control systems" to store their source code. The most common programs here are CVS and its newer brother SVN. Get used to these systems and make active use of them! Both systems allow you to "check out" a certain version of the source, manipulate this and automatically generate a diff for your changes.

If you already did this, go ahead and read the next 7 rules!

4. Don't overrate yourself

You are a cool and geeky person. You do development for years and in your environment you are one of the smartest. That is great. But do not assume that this also applies to the project you want to join. Open source is usually performed by people that are heavily interested in the topic, which are sometimes a lot smarter than you and who most probably have a hundred times more experience in the specific topic. Keep cool and better be shy than snobbish. Think about answers you get from members of the project, even if they look stupid to you at a first glance or if they sound rude. Research the topics people are talking about before writing an answer. Take responses to your requests seriously, although they might sound illogical to you.

5. Acting means Karma

As said before, Karma is a sensible value, which depends on hundreds of factors. One factor is acting contrast to talking. If you have an idea for a project and you are capable of realizing it: Go ahead and write a proof of concept. If you need a feature, you will probably do it anyway and use your patch for personal use. If you have it working, goto rule 2 and attach your patch to the proposal you wrote! Still, before you act, go ahead and read the following 5 rules!

6. Be friendly and open

The most open source developers you will be dealing with, will probably do open source for years. Those are already stressed by users expecting something wrong and by new developers who do not stick to these rules, you are just reading. Remember this, when reading their emails. These guys are not unfriendly or rude, they are just busy and annoyed. You will come to a state, where you have to read 20 mailing lists with thousands of posts, keep an eye on a large number of code lines, intermediate in many discussions and interact with a lot of different people. When reading emails, just take the objective essence of the words you are reading and ignore the tone you might feel to experience.

7. Flaming is bad

This rule is almost the same as rule 6, but it is still very important. Read every conversation carefully. I know the feeling quite well, if you think, your conversation partner "is an idiot". He is not! There are no idiots out there. He just has a different view on the things that you have or has a different technical background. Stay cool, think about your reply for some minutes/hours/days and write it, when you don't feel angry anymore. Try to state your points in polite words and explain in detail, why you are of a different opinion. If you still feel anger coming up while writing, save your reply and review it later again. Flame wars are a really bad thing and pollute the communication channel of your project. They will definitely not stop occurring but that's the way it goes. The only thing you can do against this is not taking part in them.

8. Respect foreign code

Every piece of code you will see was written for a certain purpose. If you browse other peoples code, you will often think "WTF...". Don't change the code instantly to work the way you personally expect it. Get in touch with the developer who wrote the code (e.g. using "svn blame" - see rule 3). Discuss your views with him. Don't do that in public, as long as this does not affect a large portion of the project. If it does, refer to the general communication system of your project and state the issue there. Remember rules 2, 3 and 4 here at any rate. If you cannot decide, if an issue belongs there, get in touch with people you already know of the project and ask them for help. If you are kind and describe them, what you want, they will help you for sure.

9. Do not expect anything

Open source usually means working on voluntary basis. These people are (mostly) providing free software, so they are not making money with their hands work. They are doing so because of different reasons. Some are just idealistic, others simply want to share something, some want to profile themselves, others want to make money with the services they provide in addition and even others have everything in together in mind or even other reasons... Whatever their intention is for doing open source, they are doing it for free. Keep this always in mind, whenever you issue a request to them.

For example "feature requests" are a nice thing. They give developers an idea of what they might properly need, too. Nevertheless, most open source developers will only implement features they either need or they see an interesting technical challenge in. Don't be annoyed if they refuse to implement a feature you might need. It is their clear right to refuse it, until you pay them money to do so. If a feature request is refused or not implemented in the time frame you expect it to be implemented in, go ahead and implement it yourself our consider paying a developer for the implementation. Open source developers also need to make a living and will most probably not refuse providing a patch for you for a given salary. Anyway, they might still not include your idea into their project or implement it in a different way. Don't be annoyed! It is their right to do so! Try to live with their conclusion or try to convince them to do it differently, but always remember to stick to the previous 8 rules, when doing so.

Whatever is described before, always reconsider your idea for several times. To expect anything from an open source developer is not the way it works, usually. Doing it yourself is what is common.

10. Learning is everything

The most important idea behind open source is to learn. People provide their sources in an open way, to let other people learn from it and to learn from other peoples contributions. The same applies to any knowledge provided about the project. Just look at this article and think about why I may write it? Correct, because I want to share my experience with the open source community with anyone who is new to it and because I want to get feedback from others, to see where I still might have weaknesses and which points I did not consider, yet.

Be sure to learn something from every line you read, might it be code or conversation. You can learn from anyone out there and if it's only how you should not do something...


While writing down these 10 rules, which I consider very important to read for every new open source developer, I already have more rules in mind. But let's just stay with these 10, to give a starting point. If those other things in my mind turn out to be a really good addition I will add them later on. We'll see. Thanks for any feedback and I hope this post will be useful to every newbie...

Kore also advised me to refer to How to ask questions the smart way, which reminded him about this post, while reviewing it.** I did not read this article before (but maybe some similar), but it definitely looks relevant. If you have more resources, don't hesitate to leave a comment!

If you liked this blog post or learned something, please consider using flattr to contribute back: .



Add new comment

Fields with bold names are mandatory.