Murphy’s Law and Open Source Software Development
Q: Why do open source projects fail?
A: Because failure is easy.
You may run an open source project or a part of one. Odds are, things are not as rosy as you expected. Where are the volunteers? Where is the community? How can I make this project succeed?
The simple fact is that open source is not a guarantee of success. The real successes, like JBoss, Apache, Linux and others comes from the right mix of ideas, support and work done by members of the project. But what is required for success? To answer this question, let’s look at why open source projects fail. Using a Murphy’s Law approach can help get a grip on failures, their cause, and even a solution or two.
Knowing what can go wrong or even how things succeed can be used to keep a project on track. With thousands of failed projects and new ones coming on line every day, finding failure is easy. Time to start listing the failures you see in open source software and looking for ways to get around or to avoid failure all together.
Murphy’s laws lead to a preventative or at least failsafe solution based on knowing that failure can occur. So, if an airplane engine can fail because of one of a hundred possible reasons, odds are if you have two engines, only one will fail at a time or at least run long enough to get back on the ground. Knowing the failure gives you a chance to look for solutions, like an extra engine, over building, backups, alternative paths, etc. If it can go wrong, it will, so prevent or have a way to live with the failure. This is very simple logic that can be applied to open source development.
Law Zero: People are the source of all failures, especially when they are perfect
People do the work and people make the choices. If your tools are poor, that’s because people built the tools and people use the tools. People are not perfect and thus most things we create have a flaw or two. It is not just stupidity either. For the most part we are all quite smart. The problems come from assumptions, shortcuts, emotion, politics, and of course limited time and resources. Add to this an inattention to a missed detail and working past our limits, you get an almost infinite variety of errors.
The worst offences are times when errors and the failures they can create are discounted. Looking at open source, we expect that because there are great projects like JBoss, we can expect the same for any idea. The facts however, from my point of view as a community leader at java.net, is the likelihood of any one project reaching greatness is very low. It is true for most communities and other open source sites like SourceForge.net.
There are two ways to reduce human frailty: Reduce the involvement of people or use process. There is of course a hidden solution: Use people that make fewer errors. How do we prevent failures of open source projects? The answer is that it is a mix of things. Failures come from many sources for various reasons, therefore we need a mix to prevent a critical mass of failures from stopping success.
The remaining laws should be looked at as a set. Each law is important in some way to a project. No one failure, once corrected, guarantees success. Also, some of these failures happen at different points in the lifecycle, so they are not as problematic at other times. Some of these are important throughout the life of the project and need to be a priority in the project’s management. As a project owner or a member, use this list to help start your project and throughout its life.
Law 1: The worst project starts with a good idea
This law is so true it hurts. If you look at java.net or SourceForge, you will see the litter of hundreds of good ideas and no source code. At java.net, in general we approve most projects and many are based only on a good idea. Some succeed, but many more fail to grow.
In the Global Education and Learning Community (GELC) we have an incubator area for new projects. We do this because of this simple law. It helps us manage the dead wood and isolate them from active projects. Most of the projects are dead soon after they are proposed. The primary reason is that many think that the community will come to their aid and help their project become a reality. The fact is that there is usually not enough of an idea worth considering.
Why is a good idea a source of failure? There are quite a few reasons, all of which are based on human psychology. People in general hate the idea of work. Even worse they hate working without direction (many failed projects are proposed in less than one badly worded sentence). To add to the problem, many ideas are just that, an idea and nothing more. Very often the proposition fails to account for the fact that a solution to a problem has never been found and is likely impossible or very hard. Like proposing software to create world peace, nice idea, but how do you implement it? Developers are just not attracted to empty ideas.
The best way out of this fact of life is to start a project out with an already working version or a detail design. Ideas alone will only attract flies. For many, what this means is that the originator need to build the first version or a very functional prototype.
Law 2: Build it and they will come and do nothing
Admittedly, this law contradicts open source law 1. But if it is a good law, it is worth contradicting.
Build it, and they will come is a hallmark of successful projects. Even if it is just a seed, we see potential. Look at Ant, the highly successful build utility. James Duncan Davidson solved his few problems related to building and testing Jakarta (open source version of Servlets) and then released Ant to open source at Apache. Ant is now the number one way to build Java applications verses the prior solution: Make.
Ant is a simple idea, very useful, clear in its execution and its documentation. Better yet, Ant had the ability to be extended by adding new commands. Ant is now thriving as new technologies and techniques extend its usefulness. The open source community around Ant is now huge and quite successful.
Not all projects will attract developers or even users. The simple fact is that we need several things to make a project inviting. One of them is that the software is useful and in a complete contradiction, annoyingly incomplete. Unless there is a need for growth, there is no reason to add code to an open source project. Ant is a great example of need and a place to hang the solution. Lots of volunteers have extended Ant to make it fit their needs. Without this need for change, there are fewer developers to be intimate with the code and thus fewer people to fix bugs and support users. It is a cascade of possible failures if there is no reason for developers to work on the code over time.
There are also a slew of flawed applications that you would be insane to add to because of their complexity. Some open source is just plain garbage. Why would anyone want to make garbage smell nicer? It’s still garbage. So the code has to be worth fixing or extending in the first place.
Good design, well-written code, clear documentation, a useful idea that people need, and room to grow. Together they will make a great open source project. Loose any one of these, and you are on the road that can lead to failure.
Law 3: Membership has no privileges
Many people believe that joining an open source project means that they can request new features, or even add the features themselves. In simple fact, membership usually means you have the right to complain. Of course, with most complaints, there is no guarantee that you will be heard.
Most successful projects have hurdles to getting your way. Open source is usually controlled by a tightly knit group of developers. They usually have a process to review ideas and come to agreements before change is allowed to occur. Of course if you are a member of the ‘inside’ group, change is a little easier to do. But if you don’t play by the rules, you could be kicked out. The different levels of membership from observer to developer to project owner are a key part of open source development platforms.
Projects that do not regulate privileges have two types of failure. First is the obvious one of uncontrolled change. The second is less obvious. People act differently when trusted. If you earn trust and are granted authority people act a little more responsibly because they fear a loss of authority. When granted authority without earning it, there is less value put upon it because there was less work to get it.
Sometimes it takes years to get commit status on a project. The key is to follow the rules and work hard at gaining trust. This also ensures that you become not only familiar with a system, but that others can trust you and that reduces their need to micromanage your efforts.
Law 3: Open source is closed until further notice
The ‘open’ in open source software does not really mean open unless it’s what we want you to see. Open source has so many hidden rules that it is hard to play the game sometimes. It is a mistake to believe that there is a hippie like free love and software society behind successful open source projects. The fact is that ‘open’ only applies to your ability to read the code and to use it as you see fit. Modifying the primary code base is only at the will of the owners. Although we like free love, we use protection in the form of trust and rules to prevent unpredictable change.
The problem is that when a project is popular, there are a lot of people that would like to add to it. The reality is that gaining trust is a long process so adding new developers to a project is not a viable solution.
There is one way out of this dilemma. Simply you need to have an extension mechanism. This allows another developer to create their own project and just concentrate on extending rather than modifying the core code. Not all applications are capable of being extended, but those that do are better off with a strategy that offloads extensions to other projects. Look at NetBeans, Eclipse, and Ant for great examples of this.
Law 4: Most volunteers are just lookieloos
A lookieloo is just someone interested in looking and providing nothing. The term comes from realty agents and refers to people that flock to open houses just to see what is inside without any intent in buying a house. It is also a term used on freeways as a term of scorn for those that slow down on the freeway to get a good look-see at a traffic accident, only to slow traffic for others. Simply, most volunteers to open source projects supply about the same value. They waste your time and provide nothing.
The simple facts are that they are either incapable of helping because of a lack of time and/or skills or they just don’t have the real will to get moving (see law 5).
There is really little you can do about this problem. The key is to understand that lookieloos are real and that they do not represent true value. However, do not assume that they are permanent lookieloos. Some can become active members in the future. Thus, despite their annoyance, it is best to keep them around. Avoid having rules that cancel memberships for inactive members.
Law 5: Managing open source volunteers is like herding cats
If you look at the change logs of most successful open source projects, you will only see a few names and in many cases, just one name. The reason is that a small group or just an individual does all the work. The key reason is that volunteers are just plain hard to motivate. Motivation is hard!
Back to herding cats, there is little that really motivates a cat that can be used to train it. People are really very similar to cats. Look at what open source participation offers: no cash, little recognition, and hard work. Not much more than a sense of accomplishment and many can get that from watching the 10th season of survivor. Where do volunteers come from? A lot of volunteers come to projects because they need something. They have a scratch that needs itching. Some are willing to contribute to make the changes they need. But this is a mixed blessing (see law 6).
Law 6: Volunteers will work on really annoying problems – just not the ones you want them to work on
The best work you can get from someone on an open source project is when the developer has a problem that affects them personally. The problem is of course is that it may not be your problem or a priority to you or a majority of users or team members. This is back to herding cats (law 5) because the cat is just going to go its way and is little concerned with your priorities. If you are managing the project, you got to take what you can get if you can. If a developer has working code and it does not get in the way of other changes, go for it.
If you are in charge of an open source project, use barter to get some work done in trade for the developer working on a favorite addition or fix. Trade a developer’s ‘must have’ for something off the project’s priority list. If you are a developer trying to get approval for your off-topic fix, go for a similar offer to work a priority item.
Law 7: A lack of documentation and examples will waste your time
More work equals less work. The more you put into explaining an open source project, its design, its code, its bugs, its use, and its future, the less time you will waste managing developers and users. The problem of course is the most of you are coders and not writers of manuals. Worse still, though we may plan our development, we are bad about keeping design docs up to date (see law 8).
One real trick is to write everything down and publish it as part of the project. A bit difficult to pull off for many, but it can be done if you have the will.
There are a few possible ways to tackle this problem. First is the Wiki. A Wiki allows for more people to participate in developing the documentation. It is sort of documentation by opportunity. If you find something missing, it is simple to add a new entry or add/modify an exiting entry. Less trouble than checking in and out documents and no issues with incompatible editors, so a good solution for many. Wiki is catching on and becoming the primary way to document many projects.
A side issue of course is that everyone needs to know how to use a Wiki (What came first, the chicken or egg? Why the egg, because it must first exist!) . Wiki is simple, but it is still a different medium that is in no way like using something simple like a text editor or as full featured as a word processor.
Another way to document a project is with email list groups or forums. Usually there is enough dialog between developers and users to document both the code its use. As a searchable source they can help make a reasonable bit of documentation. However, the information should be moved out of these mediums to a Wiki or printable documentation. A person should be able to look at the relevant documentation (Wiki/html/text) for 95% of what they need.
Law 8: Open source documentation is a death of a thousand cuts
Open source documentation, for the most part, sucks. A large part of this is that open source projects are usually a moving target. Each change in the code may cause a change in the design, the code documentation, and the user documentation. Keeping the docs up to date is a constant problem.
One way to get more documentation and to keep it up to date is to ensure that each change or added feature is documented as part of your process. Many projects rely on issuezilla or other issue management system to document changes. The problem however is that issue systems are usually not easy to search and rarely answer the questions asked by developers or users. Changes, if they change any behavior should cause a change in both design and user documentation.
Law 9: Only a good process will create a successful open source project, but most open source developers hate process
Many believe that anarchy is the norm in open source. The truth is that most projects are run by the owners acting as dictators (Linus Torvalds is an excellent example). The open source process in most projects consists usually of an issue, then a proposed fix, a review, and if the review is positive, the code is committed. In some cases there is more to this, like requirements to add to JUnit tests, documentation, and others. The owner (like Linus) and lieutenants (Linus has a group of trusted developers that have similar philosophies and are highly trusted by him), set these rules and act as the primary reviewers.
Process can be complex or simple. A project might require UML documentation or to follow a specialized release schedule. The more process you see, the more stable the code is. This is something that is almost odd given that so some projects and the public perception of open source is anarchy. But projects based on pure anarchy are not successful. Why should they be? No one likes unpredictable change.
But many hate process. We might think we are smart enough without getting approvals from the key developers or that certain rules do not apply to us or this or that change. A lot of developers are drawn to open source because they hate the slow process they are exposed to at work. We see open source as freedom.
The reality is that process, even in small amounts, when added to software development can greatly improve things. Yes, a good developer might be highly productive without a process, but teams are less so. The simple reason for this is a way to increase understanding and ensure some unpleasant tasks (like documentation) are performed.
A single developer might be able to keep it all in their heads. Add one or more people and you get a decrease in understanding. Add users and the problem gets worse. Include the fact that the team is geographically separated and face-to-face meetings are unlikely,
Process is for groups. Discipline is for the individual. We need a lot of the first and enough of the second to ensure that the process is followed.
But what of open source anarchy? Anarchy is often on the front end, with a person that sees a need, creates the first version and then opens it to the community. After that, process needs to follow if others need to be involved. Exceptions to this rule are abound, but these are projects that are still run by a lone developer.
Isn’t anarchy what open source is about? The freedom to do what is right! Do what you want, ou are smart enough, right? Well, as said, anarchy happens, but look at the successes in open source and you will see leaders, communities of like-minded people, and process.
The simplest process in open source follows this simple set of rules:
Issues must be associated with all changes
Code must be approved by at least one other developer with commit authority. Any negative reviews should be resolved prior to commit
If the code change affects documentation or unit tests, these should be updated at the same time as the code
Commits to the CVS should be annotated with the issue number, the reviewer’s ID and any documentation about why and how the change is applied.
Law 10: Power corrupts and absolute power stagnates projects
I hate to say it, but most lone wolf developers are horrible at understanding how other people think and thus end up writing for themselves which makes it even harder to understand (the worst is someone with a perfect memory!!!). The lore of the great hackers is filled with stories of the unencumbered developer creating a great piece of software. There are also horror tales about the teams that had to take over such software that was almost impossible to understand. It is the transition that can kill a piece of software. But in open source, it is possible that the great hacker never releases control of the project.
I have seen dozens of projects that have just one person authorized to modify code, the original owner of the project. There are two reason for this. The first is many of the other laws is in affect and no other developers are remotely interested. Likely this is related to how the project is documented. The second reason is that the developer is not allowing other people to touch code in fear of change and fear of comment.
I use ‘fear of change’ and ‘fear of comment’ because these are probably two of the most visceral emotions in developers. We hate it when someone changes our code and worse we when someone talks badly about our code. We have a fear that someone will find our inelegant hacks or destroy our elegant ones. Try it. Just pick a random piece of someone’s code and call it a pile of Christmas dog vomit and see what happens.
This problem with change is we put our sweat into the code. Any change threatens our labor. There is inertia that makes us panic when someone changes the direction of our code. It could be good code or bad and we will avoid change before even considering why a change is being proposed. Look at most arguments from original developers. They are mostly negative about why a change should not be applied.
The solution is to just not let it bother you. If you look at such change as improvements to your code, the changes are easier to take. The whole reason for opening up your source to community development is to get other peoples wisdom. Take it and use it to better yourself and your code.
There is an opposite problem with this law as well. If you imagine we hate others changing our code, the other developers are often reluctant to make the changes. Simply, some people are afraid of our response. If you have been burned by someone maligning your changes as a knee jerk response (usually with a lot of venom), you are not likely to submit changes. The solution to this problem is to make sure there is plenty of commentary on your project about obvious changes and that there is always a need to improve the code. Make it easy for a developer to know that changes will be accepted if well thought out. It never hurts to assign an issue to get someone thinking that changes are acceptable.
Summing up
The difference between success and failure is sometimes slight. But I really am surprised by how many times the reason for failure is obvious. Recognizing the source of failure is just half the job though. Success takes planning and a lot of hard work. Luck is all about being prepared and ready for the good and prepared to dodge the bad.
Some of you may disagree with some of my reasoning. I can almost guarantee that you base the disagreement on something that occurred in your past. Well, history teaches us many things, but it can lie when it comes to why things succeed or fail. Just because something happened in the past does not make it true in the future. There are too many variables. Basing a solution entirely on history is not enough. This is really another law: If it happened once, it is not going to this time – especially if you are sure it will. Look to what works most of the time, rather than single examples. But, be ready for new failures and try to predict them before they occur.
That’s a start at the Murphy’s laws for open source. There are a lot more that we can get to later. If you would like to suggest a law of your own, please write me at Turbogeek @ cluck. com.
Want more Murphy? Take a look at one of my older articles: http://www.informit.com/articles/article.asp?p=26441&redir=1
Comments
Comments are listed in date ascending order (oldest first) | Post Comment
I’ve noticed there’s a certain strength in the leaders for these open source projects. Also, having even a few people seems to jump up the chance of open source even having a chance at success. Most of the sourceforge net failures seem due to individuals. I’ve volunteered for some OS and had some mild successes. Some concepts on how to improve particapation: * kill cvs, really, what a piece of junk * examples are awesome, is there a plugin like JUnit someone can make that can auto-generate examples * plan, plan, plan. especially with more then one person. 2 people is a little disorganized. 4 is just completely unknow. excel, quatro pro should be fine
Posted by: smartinumcp on December 30, 2004 at 12:53 PM
Daniel, that’s a really good piece of information. It should be in the java.net FAQ or something.
Psychology is the base for every decision, which you seem to have a very good grasp of.
Cheers,
Mikael Grev
Posted by: mgrev on December 31, 2004 at 04:40 AM
Another law: Its not easier to recreate some library then to depend on it
I have seen this many times in open source projects there is some core library thats really great.
The core is just an idea that allows other, known technologies, to be re-invented in whole new ways. For example; this imaginairy project allows partitioning a piece of software in groups. And now unit-testing done in groups looks really nice. Well, we could depend on JUnit, but we would probably have to change some of its code and the re-ship it. Hmm, its probably easier to rewrite JUnit from scratch and not having to be bothered with reading and changing other peoples code. Even though that code has seen many eyeballs.
the end result is always that the rewritten code is very low-standard since writing it was more work then originally thought. The project dies since nobody wants to work on something thats not even near as good as the thing its suppost to replace.
Gradual changes and temporary forks are what allow non-corporate sponsered projects to go forward. Make it work; but postpone a better structured rewrite.
Posted by: zander on December 31, 2004 at 05:34 AM
Simple Law – “Any other reason to avoid discontinuity”. Already spoken above, where lookiees are allowed to keep looking. Basically maintaining a facade or breeding ground for want of an elite fighting force. But let me emphasise in different light. You see with the web up 24X7, you pretty well have no further overhead to continuing any effort. And it has to be ‘other’ reason where you haven’t look such as asking a group to add to the bazaar effect, just long enough to draw attention, and dissipate your dictatorial gripe; the place becomes friendlier when there are real friends in there. Or if you re far ahead, showcase as part of your lecture to some class and get them testing out for the academic notion of it. Any other reason has got my http://red1.org/ going thus far 🙂 *coughs*
Posted by: red1 on January 03, 2005 at 10:10 PM
Another one: Maintenance is boring As stated managing an OS team is like herding cats. Programmers don’t like code maintenance and debugging (well, most of them, I guess there are some who find perverted pleasure in it). If there’s no incentive, most won’t be fixing bugs when there’s new features to add. This is what causes the attitude you get a lot from OS groups when you report a bug where they scream at you “fix it yourself or become a donator and we may look at it” or similar words. Many of them are just not interested in maintaining their product (unless it’s such a massive bug it influences core functionality for the majority of users in which case the problem can cause bad press which is bad for their egos).
Posted by: jwenting on January 04, 2005 at 01:07 AM
A couple years ago I launched what I coyly refer to as my contender for the least successful open source project in history. Sure, I got some downloads and people expressed interest, but I couldn’t even get so much as a suggestion out of the community I was courting. The disappointment was real, but I wasn’t really so surprised; it was my first time out and I had some baggage to unload. I was consciously engaging in boundary testing by ignoring proven practices and I was making a habit of being forcefully outspoken with my personal opinions to see how fast I could make the cluetrain go. I may as well test my luck marketing a sandstone sex toy. On the other hand, I read these rules of thumb and know that they are all true. There is no guarantee that a different tack would’ve produced any different results.
In the end, rather than be crushed by defeat I was relieved because throughout the effort I was being reminded that the software wasn’t ready and that I wasn’t ready. Having a user community would’ve been a hindrance to what I contribute as a rule I think you missed: Sometimes the best way to move forward is to start over again. I’ve seen painfully sweeping redesigns in countless other successful open source efforts, and each one makes a claim to necessity. I just count myself lucky to have the opportunity to try again with a considerably improved mousetrap. As I begin a new, more methodical journey this year, I will keep this guidance in mind. Most importantly, I will be prepared to fail all over again, content to know that what it’s worth won’t ultimately be determined by traditional measures of success but rather by my own evaluation of how earnestly I made the attempt.
Posted by: mentata on January 05, 2005 at 09:26 PM
