Today I ran across a thought provoking article on Dr. Dobbs. The thesis is that there is a perception that Open Source projects copies what already existis and it's in Closed Source where the real innovation occurs. This perception exists in part because how geeks choose what to work on.

There is most definitely evidence to the contrary and also to support that perception, but the main point of the article is that there is a fundamental problem in Open Source which manifests itself as this perception. The problem is with project selection.

Now, Dijkstra wrote a memo in 1982 that describes 3 steps to use when selecting a topic for your research. These rules translate really well to hacking and all geeks should consider them when selecting an Open Source project to work on. The rules are:

1. Raise your quality standards as high as you can live with, avoid wasting your time on routine problems, and always try to work as closely as possible at the boundary of your abilities. Do this, because it is the only way of discovering how that boundary should be moved forward.
2. We all like our work to be socially relevant and scientifically sound. If we can find a topic satisfying both desires, we are lucky; if the two targets are in conflict with each other, let the requirement of scientific soundness prevail.
3. Never tackle a problem of which you can be pretty sure that (now or in the near future) it will be tackled by others who are, in relation to that problem, at least as competent and well-equipped as you.

Let's break this down a little so it can be easily digested.

Rule 1 is an internal one and it tells us that the obviously possible should be shunned as well as the obviously impossible: the first would not be instructive, the second would be hopeless, and both in their own way are barren.

Next, Dijkstra was refering to scientific projects, but Rule 2 can be easily mapped to software projects also.

Rule 3 is the most important from an Open Source perspective. It ensures that your contributions are unique and move the-state-of-the-art forward. As Dijkstra so eloquently puts "If others will come up with as good a solution as you could obtain, the world doesn't loose a thing if you leave the problem alone. A corollary of the third rule is that one should never compete with one's colleagues. If you are pretty sure that in a certain area you will do a better job than anyone else, please do it in complete devotion, but when in doubt, abstain."

I will be applying this rules to my future project selection. I hope you do too.