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.