There are features missing, so we start at 0.0.1-alpha1 …

There are thousands of projects, which have a version number that starts with a zero. It was common to do so many years ago and strangely enough, there are still projects that do this today. During the “Web 2.0″ hype it was even en vogue to put “beta” stickers in the logo, so the “unfinishedness”  was promoted to a positive signal that expressed that the project was dynamic and evolving. While that point of view is somewhat understandable, it’s somehow “dangerous” too. People often don’t take projects with a zero in front not seriously. Many projects even classify their status as alpha or beta for many many years. Nevertheless, they release new versions to the public from time to time. How can this be, if the project is not ready for use?

A common misconception is that a project that releases something with a 1.0 is finished or has completed the vision for the project. Another “advantage” of the leading zero is that you can react to critics that the project itself is not finished and the complains will be resolved when 1.0 will be released. But are there critics that complain in this way and if there are, do they really buy the argument that this is due to the beta status?

I think not! When you are so satisfied that you want to release a stable version to the public (I exclude “real” beta versions and release candidates here), then you should consider to start with a 1.0 when you use this kind of version number scheme. It’s not a problem if a 1.0 release is not feature complete, that is what future releases are for. Just use 1.0 for the first release where your software does something useful (otherwise it wouldn’t make much sense to release, doesn’t it?) and then go up from here in your self defined steps. The common scheme is #major.#minor.#patch, where #patch is increased by (security) bugfix releases, #minor is increased when smaller changes have been made that are usually compatible with the prior releases with for example saved files, interfaces, … and #major is increased by big changes that the team considers as big step ahead. New major releases are also a good point in time for breaking compatibility or getting rid of deprecated stuff.

Using a reasonable version scheme with appropriate numbers, people will take the project more serious, business users won’t get a headache when they have to convince their boss that the 0.0.1alpha3 version of your project is more stable and reliably than the version number suggests. Don’t get me wrong, a version number does not make the your project more reliable, stable or whatever, it just changed the perception of the project and provides a more professional “look”.

Alternative schemes

Another thing that has established at least in the last decade is that major or sometimes even minor releases get code names that make them memorable. Ubuntu for example uses alliterations like Karmic Koala, Dapper Drake etc. to name their releases (major + minor according to the scheme above). KDE has code names for their beta series for a release. This makes it a lot easier in communication with your users and within the team to speak of the karmic release than release 10.04 or the 1.2.x series. Some projects follow a strict pattern in choosing their release names, for example Debian uses toy story character names, if you need plenty names, you might want to have a look at names appearing in the lord of the rings series. ;-) Another reason for assigning names to releases is as reminder of project members that died, this has happened to the postnuke project and the next series was named the “Adam Baum” (Greg Allens pseudonym) release. He lost his life in motorcycle accident.

Another thing that might be worth mentioning is that there are more schemes than the major.minor.patch scheme. The decision whether a new release is a next major release or just a minor or maybe even if the minor version should be raised by two or more may take quite a lot of time and some people are really serious in this area and escalate this decision to a full blown conflict. You might also just use the year and the month as version number or year and a running number for the releases of the year, example ubuntu like #year.#month (9.10, 10.04, …) or #year.#counter (10.01, 10.02, 10.03, …). This has the advantage or disadvantage (depending on your point of view) that people see in a glance how old the release is, so this may be only usable when you have a more or less steady release schedule with at least one release per year. I like it for projects with a  high visibility, small tools won’t benefit from it, but it’s worth considering, when you plan your release strategy and decide the version number scheme.

One last thing about creative version number schemes…
Don’t use only code names or start decreasing version numbers without a reason or you will bring projects like the linux distributions into trouble, because their package managers depend on version numbers that are only increased. Otherwise their update functions will fail. This also is a problem when you’re changing your version number scheme after a while, so don’t forget your distributors!

Conclusion

Version numbers are not an easy topic, implications on the perception of the project are not always as easy to grasp as we’d like to. So spend at least little time when the project starts to release stable versions. 0.x version numbers and beta stickers are out. People like reliable software that takes itself and it’s users serious.

Disclaimer: It’s sad, but there are many examples of bad leadership in the open source sphere. I normally don’t want to do name calling, but I think that  learning by example is a good approach in this case. If you feel insulted by one of the examples, feel free to drop me a line and I’ll rewrite or delete the example.

Are you a ruler or a leader?

You have started a project and it’s your baby. You have a few people helping in the project and they trust your decisions. As the project progresses, conflicting interests appear. Maybe it’s because of the main direction of the project or just features someone wanted to implement that don’t fit in your agenda. This happens a lot. When this has happened before and their ideas have not been appreciated, then often the people step back and don’t do the stuff they’d like to accomplish.

This may be the result of a general pattern that has established in your project. People don’t step up to their opinions because they’re used that they can’t get through with it anyway. At least they think that this happen. This is a dangerous state for a project. People will be drawn away from the project in the long run or maybe a revolt will form and the project is forked by the disappointed members.
So what can you do to to prevent your project from going down that road? It’s as simple as it’s important: treat your project members as equals! Of course a project needs someone who makes sure that the project has a clear vision, but try to keep a balance between the vision and the reality. Maybe the vision just needs to be updated to reflect the vision of the whole team. The difference between a ruler and a leader is that the leader is open to eliminate or postpone some of his wishes in favor of wishes of the team or team members. This creates a more open environment which enables the project to grow and prosper.
Long story short: Try to keep an open mind for input from your team and your users. Periodically reflect if you are really listening to them to make sure that a bad atmosphere not slowly sneaks into your project.

Your behavior influences the reputation of your projects

Even if you are nice and understanding to your team members (or you don’t have any yet), be aware that your behavior in forums, mailing lists etc. is visible to others. It’s sad, but there are many people out there who don’t think about the effects that their behavior has on their online reputation. Some people even don’t care and misbehave in publicly visible places.

There are many prominent people with – let’s put it that way – questionable social skills. Starting with more or less rude behavior of well known “open source gurus” like Linux Torvalds, whose rants are widely known. But there are also people like the author of one of the best cd/dvd burning programs for linux/solaris/… who is known for his rude behavior. Linus has earned enough reputation that his behavior has no bad effect on his projects like git or the linux kernel and his projects have many people who join them or want to join them. On the other hand, our good friend with the cd/dvd burning application is more known for his rudeness and you won’t find many people that really want to work with him.
In short: Be nice or your project and your “karma” may/will suffer!

Conclusion

There are many things you can do wrong when you’re communicating with your project members or in public channels. Keep in mind it’s a good approach to treat others like you want to be treated yourself. This often helps to keep your communication straight and honest. I like the concept of karma that Tobias Schlitt mentioned in his blog post. And you don’t want to mess with karma, so be nice! ;-)

References

• http://greg.chiaraquartet.net/archives/171-10-golden-rules-for-running-an-open-source-project.html
• http://schlitt.info/opensource/blog/0541_10_golden_rules_for_starting_with_open_source.html

So you attracted a new member…

Especially when you’re team is small, then it’s a big deal when new people join it. You are eager to integrate them, but there are many things you can do wrong and drive them away from your project. It’s not an easy task if you are not used to it to get someone involved. And you always have to take care that you don’t ask too much of the new member or bore him to death. In short: when you have a new member, try to keep him interested but protect him from “information overload”.

“Here read this comprehensive guide…”

There are projects like debian for example, that have a pretty rigid recruiting process. You have to prove worthy for a long period before you gain the rights to really participate. There are other projects out there that also follow this principle, which basically is based on mistrust on new developers. That is understandable for projects that are as big and popular as the debian project for example, but this approach has several disadvantages that you should keep in mind. Your project has the possibility to keep only the “best” developers and discard the ones you don’t like in the process before they can do harm. This sounds good in the first place, but you also discourage many good people from trying to get involved because they don’t like to be treated in this way. And even the people that survived the selection process may turn out as “malicious” in the long run. Long story short: think about the negative implications before setting up a rigid process.

“He joined and was never seen since… :-(“

One thing that you’ll notice very soon is, that people are very excited about your project, do everything to join it and maybe even start some tasks and suddenly they keep a low profile. You’re trying to contact them and receive no answer on your mails, IM messages etc. Many people think that they have done something wrong and repelled the new member. But the truth is that this happens a lot. Sometimes the people will write back a few months later and apologize but most of the times they play dead after they realize that they should have contacted you because they are embarrassed. When something like this happens, think if you might have done something wrong, If you find nothing obvious, you can be pretty sure that it’s not your fault. Long story short: people sometimes disappear because of personal reasons –  this is pretty normal, get over it.

“OMG he killed our source code repository…”

When you’re project is very small and new people join, then it’s not unlikely that you want to integrate them as soon as possible into the project. So you’re giving them administrator rights at sourceforge and the password to the webserver to keep them busy and give them the freedom to help in any way they like. This sounds silly if it’s written down in compressed form, but this happens and sometimes this has negative consequences. The new member might damage parts of the infrastructure either intentionally or by accident. This is not unlikely, because especially non-linux/-unix people have often problems with shell access, ftp, file permissions etc. In short: Take care that only people you trust and who know what they are doing get unlimited access to the core infrastructure of your project!

“He is so lazy and always asks dumb questions…”

Some people expect that new members have from the start a complete understanding of the sourcecode and the underlying infrastructure, of course they also should know all the tools they need. If they don’t then it’s their duty to learn it before they ask dumb questions… Another variant of this behavioral pattern could be described as “fire and forget”. You introduce the new member and then he is on his own, without help and guidance. Sadly quite a few projects act like that and many new members get disappointed and leave the project soon. It doesn’t have to be this way and even when this is a spare time project, the “old wise members” should take some time and help the new members. Just because they don’t know everything yet doesn’t mean that they won’t be helpful members after they got properly introduced in the projects technologies and procedures. To summarize it: there are no dumb questions, only dumb answers! Take your time with the newbies it’s worth it!

“I do my very best to help him…”

The direct opposite of the mistake above is that the project is too protective and too “kind”. The new member is bombarded with good advices, links and help offerings. This may as well drive people away. It looks desperate and may drive the new members crazy. Offering too much help introduces a feeling of pressure, even if it’s not meant this way. In short: Don’t exaggerate with help offerings, try to balance between negligence and over caring.

Setting up a process helps

To avoid the problems I have mentioned above, you should think about introducing processes. This might sound boring and you don’t like it, because it reminds you on your work, but clear guidelines help new people to fit in the group and learn the processes that exist anyway, no matter if they are written down or not. Thinking about the processes helps to improve them. Consider for example check-in or code style rules. Every project needs some kind of common understanding in theses areas and new people need to learn these. Without written down rules, they have to do trial & error which can be pretty frustrating. Even harder are social rules like who is responsible for what and who decides when there are conflicts. You should consider if it’s possible to assign a mentor to the new member, so the new one has one dedicated person to ask questions. But the mentor needs to be motivated and willing to help. Otherwise it will do more harm then help. Long story short: By formalizing the internal rules and roles you make it a lot easier for new people to blend in.

Knowing their motivation

Everybody who joins a project expects something in return. Some people like to participate in publicly highly visible projects to get reputation in a field, others just like to code and practice their profession or hobby. Of course there are much more different aspects why someone joins a project, but as a project lead you should try to find out what the motivation is and help the members to get the most joy out of their involvement. You can do this by giving the right tasks to the right people, giving credit to the team or even assigning roles to people, so they can do what they like most.This way you can maintain a healthy project with satisfied members. As a summary: Knowing the motivation of your fellow team members and acting to fit their needs will greatly benefit our project.

Comprehension

There are many ways to drive people away from your project, but there are also many ways to attract them if you do it right. Take your time to introduce new people, maybe select mentors that help the newbies in the first few months. Be clear what you expect from people and where you help them to shape their expectations and prevent them from being disappointed.

It’s more fun if you don’t do it alone

As mentioned in the second blog post, open source software exists because passionate people join in team and produce software. Working together is a great aspect of being in an open source team. If you have never worked in a small/medium sized team with nice people, then you’re missing a great opportunity. When you’re working in and with the team and you’re spending hours in mailing lists and chats, then you’ll have the chance to form friendships with your team mates. Team meetings are also a nice way of getting to know each other. I’ll write a separate article about this later. So please keep in mind: Working alone is boring. Collaborating is fun.

Training social skills

Rumors exist that IT affine people are socially “not that well educated”. Participating in a project is your chance to change that, if you’re belonging to this group. ;-) When you’re in a team, sometimes conflicts happen. Especially when you’re the project lead then you’ll have the chance to exercise your conflict solving skills. Small teams are normally pretty easy to handle, but starting at medium sized teams you’ll see several kinds of internal conflicts or struggles, which are perfectly normal when a group of people comes together. There are always some people who don’t like each other or can’t integrate in the group. If you notice that, then you can try to help in solving the conflict. This is great for training this kind of problem solving. Things like this will happen in your work life anyway, so it’s better to practice when your career is not in danger, when you mess things up. ;-) So as we all know, social skills were getting much more important in the last decade. In short: Being in team can improve your social skills – try it!

Communication training is expensive – helping in a project is free

All well running projects require a lot communication, either internal or external. Especially for non native speakers, it’s a chance to improve their English. Most projects use English as their default language to make it easy for developers from any country to join the team. If your project has no one who handles the external communication, it’s your chance to step up and do it yourself. It’s a good training and depending on your user base you even might get some constructive feedback on your announcements and other form of communication. Long story short: Communication is of great importance in every aspect of our daily life – take your chances to practice…

Conclusion

Working in a team is the fun part. Get something from your open source involvement back and improve your social skills. You can even train your other communication skills and your English, if you’re not a native speaker. Open source is not only for students and unemployed people. Improve yourself by helping others…