You are writing your software and everything works well. Now you want to release the first beta version to the public. Where should you put the files online? Where would people read about your project?

As mentioned in the article “The project needs a home – where to host your project” you might want to host everything on sourceforge, github or whatever hosting site you select. They often provide the option to put various information about your project online and the possibility to publish news. That’s a good start, but don’t forget to keep the information up to date. Nothing is more confusing than wrong information about the project, features, links to other sources of information regarding the project. That point is valid for self hosted websites as well as external hosting providers. A solution to ease the pain of maintaining the information are wikis. You can set them to read-only for anonymous readers, so only your team can change the pages.

When you are hosting the website yourself, please be aware that your server is constantly a target for hackers and when you host your source code there, it’s an even a more attractive target. Keep the software on the server up to date, be selective who gets access to the server itself. Keep more than one backup of the server to be able to restore everything in case something bad happened.

Documentation, the voluntary exercise?

People who would like to use your software will most likely need some form of guidance. Provide as much documentation as possible. Information on deployment/installation, usage of the software, developer info (if you are providing an API), etc.

But with a lot of documentation you’ll get a lot of responsibility. Don’t let the documentation be outdated or at least state somewhere where everyone can see it, which version you are referring to. Sometimes you are lucky and users from the community offer to help you with the user documentation. This happens frequently, but not on all projects! Take that chance and add these users to your team. They need to be informed about the current developments, so don’t just give them access to the wiki and let them do their work. There is a high chance that this won’t work out in the long run. They are valuable members of your team, so treat them as such.

Which additional information might be valuable for the users?

So you have a location to put information online (wiki, blog, cms,…), what should you put there? The answer is again pretty simple: as much as possible!

As a user it might be valuable to read how you can join the team or in which areas you  desperately need help. Not everyone is brave enough and asks you directly. many people are shy and don’t want to bother the team, because they may have something better to do or the user just fears to be ignored. Be very clear in your communication and people will listen.

Another very neat kind of documentation are screenshots, webcasts and online demos. It doesn’t matter if your software can be installed in seconds on the users computer. When you provide screenshots, people will more often give your software a try. In the last 2-4 years projects started to put webcasts about their software online. This has several advantages, you have some kind of “moving screenshot”, so people get a quick impression how your software feels and you have nice looking “interactive” documentation, if you do them in right way. Give it a try!

When you have a team of several developers and the projects progresses, it may happen that no one has time left to write some nice articles about the progress the team has made. The developers know that there is progress in the project, but users normally don’t follow SVN commit mails, so they may just think that the silence is the sign of a dying project. Maybe someone in the community is willing to perform these actions on a regular basis.

Single point of failure

So, now you have your domains, maybe even a dedicated webserver and a paypal account for donations. Imagine now, the people that opened the accounts want to leave the project. You have a lot of work transferring the accounts, domains, … Sometimes people don’t go, they are kicked out of the project, that’s even more bad if they had a central role in the project before. You can imagine that getting the domain from a kicked project member might be tricky.

When your project reaches a certain size you should consider to start for example a non-profit foundation (“gemeinnütziger Verein” in Germany) that holds the rights on the accounts, domains etc. This way you are safe in case someone leaves the project and you might be able to get some funding from companies that like your project. But we’ll come back to that topic in another blog post.

Conclusion

So, organizing the (one-way) communication with your users can be done by providing a homepage with the necessary information. Put as much information up there as you can handle. It will be worth it, because many users just go to the next site when the project doesn’t provide the answers they are looking for. Also be careful to distribute the ownership of assets like server, domains, admin rights etc, so the project can continue when an important person is suddenly gone. In the next article we’ll have a look at two way communication with your users.

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.

Finding your perfect release cycle

Most projects have a “on demand” release plan. When security problems occur or a stable application has been build, then a release is quickly announced and put online. This is ok as long as it is a smaller project. Especially when your project is used in a business environment, people will ask for plans and schedules so they can plan their updates. Another problem with irregular release schedules is that when the last release has been a long time ago, then people might get impatient and start to use your daily development exports or use a checkout from the version control system, that you are using (I hope). The problem is that the impatient users will lead to more and more support requests, because they are using a version that is not released yet.

So what to do? Communicate your plans early. People like to be informed. When your plan for the next release does not take the expected 6 months and after 2 years you’re not ready, then you should consider to change your plans and try to do intermediate releases. When you are planning big changes, then it’s a good idea to check if you can split your changes into smaller pieces to keep the time between releases smaller.

When you have enough time to dedicate for the project or you have a group of people that helps you to have a more or less constant stream of changes then you might consider to establish a regular release cycle like for example gnome or ubuntu (they release every 6 months). Sometimes it’s easier to determine the changes that fit in a release cycle than to determine how long a set of changes will take. The advantage is that you might even skip some changes when time is running short.

Presumably dead projects

As mentioned above, sometimes changes take longer than expected. The planned release takes a year or two longer and you’ve pulished none or just a few intermediate bugfix of feature releases. The effect is that your userbase might shrink, people start complaining, maybe even start a fork to return to a steady release cycles with more releases per year. There is also an effect on the team. Maybe not your whole team is involved in the blocking task(-s) that lead to the delayed release. They want to continue, but their tasks might not be ready when the current blockers are finished, so they are asked to wait to not destabilize the code base even more. That leads to frustration even in your team and may damage the team on the long run.

How to deal with complex changes

So there are changes that are small and medium sized and of course the big tasks that take virtually ages. How should you deal with that? No matter how good you plan there were always tasks that have a high probability to break your release plans. To solve this you can use techniques that are commonly used in “commercial” software development: feature branches!

Every version control system that I know of has the ability to copy a repository or a part of it (this is called branching) and there is another functionality called merging where you can merge the changes of one branch in the other branch and solve any conflicts where the same code lines have been changed. I don’t want to go too much into detail here, because it depends on the software you are using, but when you use this for any non trivial changes in your project, then it’s not a big deal when you are used to it.

So, how does this work? You have a main development branch which is usually called “trunk”. You plan for example to refactor a part of the system, then you branch the trunk and work on that branch on your refactoring. The rest of the team can do for example smaller changes or bugfixes on the trunk  or even other feature branches. When you like you can pull changes from the trunk in your branch if you feel that this is necessary. When you’re done, then you can merge your branch back into the trunk and your project has a shiny new feature or a cleaner codebase. The downside of this is that, when you have changed parts of the code and in the trunk people changed the same code pieces, then the version control system will complain and mark the file as conflicting. These conflicts have to be resolved manually. This happens in my experience not very often and when it happens it’s trivial to merge the changes and get the code running again. The chance of conflicts grows over time, when work is done in the trunk and the branch, but by pulling updates from the trunk in the branch you can minimize the chance of conflicts.

People often complain that this is too complex, they don’t know hot to do the branching and merging and they don’t believe in this anyway. Where does this come from? I think the answer is simple. When you don’t do branches, then you’re not “wasting” your time at the start by performing the branches and later when the merging occurs. But they don’t see the big picture. Development gets even easier when you do when you do this. You get used to branching and merging pretty soon and it’s not something you have to think a lot about. Everyone can develop their features without interfering too much with the rest of the team and when a feature is not ready when the planned release date approaches you can simply move it to the next release. So the whole team benefits from it, don’t get intimidated by some devs that are complaining. They’ll get use to it. ;-)

Condclusion

So, what have we learned here? Release plans are only as good as the techniques, you use to stick to them and purely code driven release schedules tend to get blown away by too complex tasks that have been underestimated. Use things like branching and/or discipline to establish a regular release schedule or at least be predictable and communicate your plans to give your users a chance to react, plan and look forward to your releases.

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

Delegate!

When you have started the project alone and created the first versions on your own, then you might think of it as your baby. It’s not easy to give up responsibility for certain areas. But the amount of administrative work will grow with the project. Try to find areas that you can delegate like Website maintenance, forum moderation or things like that. After a while when you know the other developers better, then you’ll find it easier to assign other tasks to them too. Just practice a little bit. ;-) To summarize this:  Try to delegate even important tasks to capable trustworthy members to free up time for important things.

“Activate” non-programmers

After a while your project might form a small community of users. They often communicate via forums, mailinglists, IRC or something like that. Then you’ll have the chance to convince some of the users to help you, even if they are not programmers. Regular users that feel connected to the project, sometimes like to help as well. Try to leverage that enthusiasm and ask if they’d like to help. They may help you for example by:

• by doing official support in the forums/irc
• help with improving the usability
• helping with the Website “maintenance”
• being the “community manager”
• design for the homepage, the UI or a logo/”corporate design”
• PR work/booth duties at conferences like LinuxTag, UbuntuCon, …
• collect donations to fund the projects
• …

In short: Don’t focus your search for help only on programmers. Every user may become a very useful member of your team.

External developer resources

Sometimes companies use your software and they need a certain feature or have other interest in your project. When you are lucky, they’ll assign one or more developers of their staff to your project (if you allow this) and they’ll work on it in their work time. Or the company pays members of your team to implement something they need. This is not uncommon, especially in projects like frameworks, EPR systems, shopping carts etc. Just be sure that the stuff they are demanding fits in your global plan. Don’t let pure economical reasons drive your project or it will soon be off the track! Other ways of getting help are sponsored events like the google Summer of Code. You can apply with your project for certain programming tasks and when your project is chosen, then google will pay a student for a summer to perform that task. This has several advantages for your project. You will get a lot of visibility in the public which may result in more people using your software or joining your project. You will have to  select two mentors that will have the chance to fly to the US and be part of the mentors camp that google organizes before the whole thing starts. But be aware of the dates. When you are late, then you’ll have to wait for the next year. And don’t be disappointed when your project has not been selected. Just apply again next year. I’ll try to find a project that has participated before and interview them for a more comprehensive blog post. Long story short: Paid development is a chance for every project to get a boost. Try to apply for the google SoC or try to find partners in the industry. Just be aware of the responsibility that the project is first, not the money!

Conclusion

So, there are many ways to find people that help you in your journey and don’t be afraid to let certain tasks go. You can’t do everything on your own and other people are eager to be part of the project. It’s important to find people that help you, if you want your project to live a long and healthy life. There are always people leaving and joining, so the bigger your team is the more people you have constantly working on it. Maybe with the google SoC or paid development you can attract even more team members with whom you can share the work and maybe even the important tasks. Try it!

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…

Just use your shared hosting account…

When you’re starting a new project, the decision to host it on your own webspace, which is usually a shared webhosting account. This may not be the best solution. When your project grows, then you might get help and you probably want other people to help you with maintaining the homepage. Do you want to give them your credentials which also has access to your private homepage?

When your project does a new release and get’s slashdotted, then your hoster might get angry or force you into a bigger webspace contract. With more users you might need more bandwidth, more memory and maintaining the software that runs the homepage might lead to a bigger workload too when you switch from a static homepage with a webforum to a full blown CMS.

You’ll also need a version control system for your sourcecode and a bugtracker to keep track of the bugreports. Maintaining these for yourself maybe pretty painful if you don’t have much time or experience with this kind of administration.

Long story short: When you’re not an administrator, decide if you are really capable of maintaining the site in the long run.

Free project hosting – but where?

There are plenty of hosting sites out there. I just want to point out two sites that are outstanding in my point of view. Of course the other sites like berlios etc. are fine as well. The hosting sites offer unlimited bandwith, preinstalled software for most tasks (version control system, bugtracker, tasktracker, …), backups and a fine grained permission system to be able to split the work among the team.

The big old man in project hosting is sourceforge. Everybody will have downloaded software from there before. They offer easy project creation, bug-/task tracker, very (very) simple forums, simple news, downloads, limited shell access, cron jobs, Mailinglists etc. It’s the all you can eat buffet in project hosting. Not the best solutions, but a big selection of services.

[UPDATE: Kenai has been suspended. Looks like Oracle has not seen it's potential :-(]

A relatively new project hosting site that has been published during the JavaOne from sun in 2008 is Project Kenai. The concept is very nice. They use standard software and provide a homogeneous web-interface. They offer Mercurial/Subversion/Git for version control, Bugzilla/Jira for Bug-/Tasktracking, mailinglists, Wiki, forums, … And you can access them vie their regular API, which is especially with jira neat, because the Mylyn integration is great. The project are not limited to java projects, it can be every technology. Have a look, it’s really nice.

In short: If you don’t want to do everything on your own, consider free project hosting, especially in distributed projects.

Dedicated server for the project

When cthe project grows you might have special needs. Then a dedicated server might be the best solution. You are not bound to the memory/cpu constraints of shared webhosting and you have free choice of the installed software. But you need to have good administration skills (in your project). Backups and security of the installation are important things to keep in mind. It’s one of the publicity nightmares for projects when the sourcecode or the downloadable files are compromised by hackers. Take this seriously or your efforts of building a great product are wasted. As a summary: Dedicated servers are risky, but they offer the most freedom. Take your choice.

Conclusion

There are many choices for project hosting. Every option has some advantages or disadvantages. Most projects will be served best by choosing free project hosting, but the other two options also have their charme.

As early as possible?

The problem with going public early is, that without any working code it’s not very likely that you attract new developers. There are so many open source projects and you have to show that your project is worth of getting help. The odds of attracting people before you have something to show are small. There is a little bit of a chicken and egg situation. You just have to put some effort into the project before you can ask other people to help. The trade-off is not easy. If you can, then try to get working code out. This has several advantages. As I have stated in my first talk blog post it’s easier to let facts do the talking. According to the 80/20 rule, even when you have written something that works, you’ll still need 80% of the time for the remaining 20% of functionality. ;-) In short: Don’t be too early with your announcements. Better try to contact potential fellow campaigners directly or with small requests in forums etc.

Power of the first announcement

You shouldn’t underestimate the power of the first announcement. If you do it right, then you can get a lot of attention with a well put news article. If you waste this situation with a simple announcement that simply states what you want to do in the future a lot of people might monitor your project for some time, but will loose interest soon. The most people will have forgot your project by the time you have something to show. But depending on the time the first release took, the project name might have a negative connotation, because people think that the project is progressing too slowly. On the other hand when you manage to get out with something that the people can play with, then you’ll have a much better standing. Especially when you manage it to release small updates from time to time. Long story short: Try to keep a constant flow of information and releases after the first announcement or people will think badly about your project.

Conclusion

It’s not an easy decision, when to go public. It’s understandable that you’d like to get help as early as possible, but in most cases you won’t get the desired result and you maybe even get frustrated and stop a promising project. Another advantage is that you’ll end up with less discussions about technologies, internal design etc. if you can show working code. This also speeds up the development, because you can do more coding and less talking.

Disclaimer: I am not a lawyer nor a license expert. Use these information at your own risk. Corrections are welcome.

Don’t invent your own!

First I’d like to point out that it’s in most cases a really bad idea to invent your own license! It may sound easy to write your own, maybe it’s even legally binding in your country, but due to the internet, your users will be located all over the world. Creating a license that is legally binding in the most areas of the world is pretty hard. If you are not a lawyer that is specialized in international law, then don’t do it! There are many licenses available on the internet that should cover almost all needs. If you have more than one license that you’d like to use you can even do multi-licensing like for example Qt did for quite a while. A wrong written license may even turn out to be pretty expensive if you get sued. For example in Germany you may get sued if your software damages the computer of a user even if you have put it under an open source license. In short: If you think about writing your own license: don’t!

More restrictive licenses

The most known license is probably the GPL. It’s the license of the linux kernel and according to the wikipedia article, it’s the license of ~60% of all software packages under free/open licenses. The GPL belongs to the group of the restrictive licenses. They are restrictive in the way that the source has to be free. This is what you might want for your project if it’s a stand-alone application. When you’re writing a library of a framework, then the GPL might not be the best solution. The problem is the formulation that “derived work” of the GPLed product needs to be GPLed as well. This line between “derived work” and just using the software is hard to draw sometimes. So it may be that you force your users to a specific license, which is bad if you try to write a general purpose software. There are dedicated licenses like the LGPL which are made for these products. You can include LGPL software in your differently licensed software. To summarize it: GPL and similar licenses with their copy-left principle may be suitable for your project, but be aware of the consequences.

More freedom, but keep my name in – license

Another kind of license are the Apache style licenses. The key differentiation between GPL and the Apache licenses is that your users can use the software for everything as long as they keep the your source under your selected license and maintain the links/hints to the you (the original author[s]). The problem is that GPL V3 software is not compatible with the apache V2 license. This means that you can’t use any GPLed library for example for your project in this case. It was a goal in the GPL V3 creation to be compatible, but the end result didn’t achieved this goal. To summarize it: Apache style licenses are easier to use for users, but may be painful for you because of incompatibilities with GPL.

Do whatever you like – license

There are  a few licenses out there that are known as “really free” licenses. The BSD style licenses are the least restrictive ones. All they require is that the original source code remains free, but anyone can use the BSD licensed work, modify it and redistribute it under another license or use it in any other software, no matter which license it is placed under. The BSD style licenses a used in a lot of semi-propriatary products and in the *BSD projects like OpenBSD etc. So please keep in mind:  BSD licenses are focused on freedom, so things may happen that you don’t want.

Relicensing?

What if you want to change the license of your software after a while? This may be pretty hard, because you have to get the permission of every contributor whose contributions are still present in the project. It’s not easy but not that uncommon. To be able to do this, you have to track the contributions closely. It is effort, but it’s not unlikely that a license change may happen. What if a contributor is not agreeing to change the license? Then you’ll have to rewrite the contributions or cancel the license change. You can prepare yourself for this and ask a permission of each contributor to change the license later. Some projects do this and many commercial based projects too. Another way of dealing with this is, is to don’t include patches from people outside the project and rewrite patches instead of applying them. The disadvantage is that people won’t be as motivated to submit patches to your project. Be aware of that. Long story short: Changing the license is hard if you are not prepared for it. Better incorporate this soon in your patch applying procedures.

Conclusion

Which license you should take depends heavily on the kind of software that you are writing and the kind of trade-off you are willing to make between freedom and usability in the commercial space (or in differently licensed projects). It’s not an easy choice, because it will have effects on the libraries you can use, on the way you can deal with source contributions etc.

There are a few sites with more or less serious guides that try to help you in the selection process:

• http://pgl.yoyo.org/lqr/
• http://home.ccil.org/~cowan/floss/
• http://swan.iis.sinica.edu.tw/LicenseWizard2EN/LicenseWizard.cgi

Take your time!

From my point of view, it’s the hardest part to find a good name for the project. A funny idea that sounded great at the beginning may be problematic a few releases later when your project reaches a certain size of the user base. For example the postnuke project had problems to get accepted in the professional space. There were negative feelings that were originated in the suffix “nuke” which has been chosen to express the inheritance  of the phpnuke project from which postnuke forked. Later when the source base has been completely rewritten the “inheritance” to phpnuke  was the source of mistrust to the project from other developers and users. So the project had to rename itself to get rid of the negative connotation. A pretty popular story of the Mitsubishi Pajero which wasn’t a success in spanish speaking communities, because pajero means “to jerk-off”. After that most big companies are spending big bucks for research. In short: Take your time when choosing the name, you may regret it if you choose it lightheaded.

Low hanging fruits first: domains

When you have a name in mind, check the availability of the domains in the important top level domains like .org, .com and the local domains like .de. They are important when your user base grows and local support groups are forming. It’s pretty annoying/confusing for you users if they can’t access the local support page by urls like http://www.myProject.de. People often work around by using pre- or suffixes like “-support”, “-community” or “-hp”, but this is far from good. Even in times of google people still try to enter urls directly and when they see a different project or a bad maintained unofficial site that deals with your project, the users may switch to different projects, because they got a (wrong) bad impression. People often don’t take the time to really search for something. When the first attempt doesn’t they’ll go on and try the next project that may cover their needs. There are many tool out there where you can check the availability of domains in multiple TLDs. Most companies that offer domains with different TLDs offer a similar service. The dot-o-mator for example offers several tools to find names and the domain availabilities. So please keep in mind: Check the availability of as many domain names as possible and maybe even buy them early for the best user experience.

Naming & trademark rights – that one may be troubling…

One thing that many people don’t think of are naming and trademark rights. You might think that it’s not a big deal, who will sue an open source project… This is happening and it will happen again. For example the Eclipse project Mylyn had a different name before: Mylar. They had to rename their project because there have been some trademark issues with other products (See: Wikipedia).  But there is more that may happen. Your users may also be the reason for troubles. Postnuke has been registered as “word mark” (Wortmarke in german) in germany and the guy also registered postnuke.de. At first he offered support forums etc. but after a while there were conflicts with some of the active members which escalated in the creation of the site pncommunity.de, which later became the de facto support site for german users. But the project had no chance to get the domain from the old owner, because he had superior righty because he has registered the word postnuke. Even the formation of the german postnuke e.V. (german kind of foundation) was not enough to be able to force the old owner to give up the domain. To summarize it: If you start a serious project check the trademark and naming rights before and as son as it get’s really serious, try to register your project name in as many countries as possible.

Renaming a project

So what happens if your project is taking off and you don’t want or can’t keep the name, for example because you’re encountering one of the problems above? First thing to do is to find a new really good name and keep all the points above in mind! You don’t want to rename it twice! Register first the domains, maybe the trademark/naming rights before you’ll go public with the new name, so no one may be able to get in your way again. After that you should make an announcement where you explain that you have changed the name and if possible, even explain why you did it. But be sure to be as neutral as possible. Don’t insult people even if they tried to do your project “harm”. Then rename everything to get rid of the old name as soon as possible. It’s not trivial to rename a project and many users may be confused if you don’t communicate it not properly. Try to keep old domains and put redirects in place to lead people that don’t visit your project homepage not often to the new site. Long story short: Renaming is tricky business! There are many things that can go wrong. Plan it accurately!

Conclusion

It’s not easy to choose a good name. There are many pitfalls and potential problems that you may end up in if you don’t select the name careful.  Legal issues, mean users or simply bad choices may lead to problems and maybe even expensive cease and desist letter from a lawyer. So choose carefully young padawan!

FLOSS needs you!

FLOSS (Free/Libre Open Source Software) exists because passionate people work on open source projects in their spare time or even in their paid time, when the company supports the open source spirit. Great projects are built by teams not individuals! Think about projects like the linux kernel or smaller projects like Zikula (CMS/Web Application Framework), they can handle the growing complexity of their particular software only by distributing the “load” on more or less people. So try to keep the fragmentation of the open source sector low by trying to participate instead of duplicating existing software if possible. So please keep in mind: Better try to join a project than start one on your own.

Communication is the key

So, when you’re thinking whether or not you should start a project, then you should take a look at other open source projects that cover more or less the same topic. It’s astonishing what is already covered by existing projects. When you find a project that fits your needs or may be altered to fit your needs, then you should contact the developer team of the project and ask if you can join the team.

Hopefully the project is alive and the developers are cooperating, then it’s better to join the project than to start your own. There are so many projects out there that cover the same area. There is a great deal of productive time wasted by duplicated work. A big percentage of this could have been used more productive when the projects would have joined and worked together.

As we all know, the world is complicated… There are projects that would fit, but you just can’t get a connection to the project. Sometimes the project doesn’t respond to your attempts and keeps a low profile. Maybe the project team is just busy or it doesn’t want help. There are also teams that have pretty strange ways to deal with external requests. Some are harsh and mean, some are too demanding. It’s understandable that this is not a project that you want to participate in.

In short: Try to contact interesting project teams, if it doesn’t work out, don’t be too disappointed!

To fork or not to fork, that is the question!

What happens when you find a project that fits your needs but you can’t or won’t join it because it’s dead, you don’t like the team or the team doesn’t like you. Instead of starting from scratch you can fork the project and get a head start. It’s an interesting alternative, because you can immediately start with the interesting stuff, because all the basic infrastructure in form of source code is already there.

Maybe I should explain shortly what a fork is. It is a “copy” of the original project, that has it’s own development team and it’s own name. You normally have to keep the license, but this is in most cases not a problem. If you want to change the license, then you have to rewrite the whole project or ask all former contributors for their permission.

Another advantage is that you have the chance to convince some of the users of the “old” project that your fork is better. Having initially a small user base can help a lot. Of course it may also be a burden because you can’t be that flexible with your changes.

To summarize it: Maybe a fork is the right solution, but keep license problems and existing users in mind!

The not invented here syndrome

Another reason to start a new project despite the (hopefully) valid points mentioned above, is that you want to do this all on your own. This is called the “not invented here syndrome”. In my opinion, this is one of the most popular reasons why new projects are started. I even started projects on my own for this reason. It’s fine to start projects to learn something, but please keep the reasons, that I have pointed out, in mind. You can learn about the topics you are interested in too by studying the code of the existing projects. Long story short: Do you really need to start a new project or is it just to satisfy your curiosity?

Conclusion

There are many reasons to start a new project, but there are also as many reasons to join projects. Don’t waste your time by starting from scratch if you can build on top of something that already works. Maybe even join a project to join efforts. It’s fun!

Do you have just an idea or maybe even started coding?

This is far more important than you might think. If you have working code you can easier attract other developers to join you in your journey. Having just an idea has the disadvantage that especially in the starting phase, a lot of time has to be spend for investigating the right technologies or preparing the infrastructure (which can be pretty boring). This will drive developers away or prevent them from even looking at your project at all. The small advantage of the possibility for other developers to give input from the start, quickly turns into a nightmare. With four developers you’ll end up with at least 4 different approaches for the problem. You have to give some “guidance” by writing code to get rid of the question, which basic direction the project should take. Another negative effect is that a huge amount of projects die within the first months and many of them don’t even publish code at all. You don’t want to be in this group of failed endeavors, so start coding and prove yourself to the community. Remember that it’s not very likely that you announce your new shiny project and suddenly a bunch of developers floods your inbox with requests to join you. The more information you put in the appropriate places like your homepage or the project homepage, the higher is the probability that you’re found by the right people. So, keep in mind: Prepare the foundation, think about the basic structure and start to implement it. Working code attracts much more than a “white sheet of paper”.

Who do you think will use your “product”?

Knowing what kind of people will build your user base is important. This will drive a lot of decisions that you will have to make. Are you just coding for yourself and giving the source to the public afterwards? This is the “easy” case. You actually don’t have to care a lot if there will be other developers. Obviously you have what you need and everything else is a bonus. When your goal is to be part or the head of a healthy project, then you have to keep your targeted “audience” in mind. I heard people complaining about missing involvement of their user base or other developers. This may be completely normal if you have a fairly small user base, because only a small fraction usually gets active. If you have only a few hundred (regular) users you have only small odds of getting something back from them. The percentage is higher if your targeted group consists of developers, but still the majority will only be passive or at most provide entries in your bugtracker. So knowing your audience helps in shaping your expectations, so you don’t get disappointed. Another thing that you have to keep in mind is that your “advertisement” on the projects homepage needs to be targeted for your audience. You can’t just provide API-Docs if your user base consists mainly of regular users, who just install the software and want to use it. On the other hand, you can’t just put up some high level feature lists on your homepage if you are targeting developers. There are many many projects out there, if you want to attract users, you should provide as much information that is interesting for them as possible (in a readable way!). To summarize it: Think about the kinds of users that you want to have and provide information targeted for them, to convince them that your project is good for them.

Do you have long-term interest in the project?

When you start a project you are of course pretty confident that it is important and interesting. This is perfectly normal, otherwise you wouldn’t want to start the project. But you should take the time to step back a bit and think if you really want to maintain and run the project for a reasonable amount of time. What some people don’t realize is that by participating in or starting of projects, they shape their “online reputation”. With a little bit of googling you can find out a lot about people and it’s not uncommon to do this. Potential employers or customers might check what the new employee or service provider has done in the past. So be careful not only how you behave, but also what you do with your projects. The Internet never forgets. Starting tons of projects that are abandoned after a short period of time may (or will?) lead to the impression that you are not capable of focusing or finishing what you have started. That’s not something that you’d put in your vita, so you need to think if before you start a project if you really want to do it. By the way, there are of course ways to start projects for example on hosting sites like sourceforge or kenai where you know that it won’t result in usable software for quite some time, but you need to have repositories to store your code somewhere. This is in my opinion perfectly fine, as long as you are honest about it and state that in the project description somewhere. So, as a summary: Be sure that you want to maintain the project or at least be honest about the kind of involvement that you plan to apply on the project.

Do you have another hobby?

This question sounds silly, but when you are in a prospering project with for example 5-10 developers, where 1-5 are “really” active, you might end up with a lot of traffic in your communication channels (mailing list, IRC, Skype Channel, …). This is not a bad thing at all. You are together with a group of usually like minded people, which may become really good friends. I have experienced this during the time that I was involved in a shopping cart module for postnuke (Postnuke is now called Zikula) and later when I was involved in the core development. You spend a lot of  hours reading and writing emails or simply chatting in the Skype channel.  This may be more time consuming than you thought. But it makes a lot of fun, nevertheless! Another thing that may be a time hog is user feedback. Bug reports, feature requests and user support may take quite some time if you want to do it right (but we’ll see in a later blogpost how this could be tackled). To keep a long story short: A growing project may consume a lot of time, be aware of that!

Conclusion

The statements above may sound like, starting a project is a bad idea. This is not true. It actually is a lot of fun, especially if you find users that like your work and/or other developers that like to participate. Just keep the mentioned problems in mind, so that you won’t be disappointed or overwhelmed by the amount of work that suddenly appears.