An observation I've heard several times is that "open source copies; closed source innovates." For contributors to open source, such as me, the statement is likely to raise hackles and elicit indignation with examples such as Linux, Boost, Apache, Cunningham's wiki, emacs, TeX, and Clojure offered up as compelling contrary evidence. These examples vary in validity, but in all cases, they represent the exception, rather than the norm in OSS. The norm is that if you go searching in open-source directories for a piece of software, chances are good that you'll find dozens of candidates, many of which are very similar. This is, in fact, how it should be in a bazaar: People borrow from each other, make incremental improvements, or adapt the product to different needs — resulting in a plethora of look-alike projects.
But beyond this incremental improvement, there is a wasteland of pure reinvention of the wheel. Someone wants to wade into the waters of writing their own editor, their own language, their own OS, and so on. They start the project and quickly come to realize it's a lot more work than they anticipated. And, of course, because theirs is one of hundreds of similar projects, they gain no community at all — neither users nor contributors — which makes it very hard for them to grind away at the needed work. Eventually, the project dies; and its remains live on forever in the repositories of open-source hosting sites. This makes for a chaotic open-source landscape in which useless artifacts continue to accumulate without the benefit of garbage collection.
I strongly believe that the core of the problem is poor project selection at the outset. Like many developers who have the "development bug," I could work on any one of a dozen projects that capture my imagination. I'd love to write a VM, do my own DSL, build my own Web framework. I could try any of these, but I know I have neither the bandwidth nor the deep interest to sustain me during the extended boring parts if no one else participates.
Given the profusion of possibilities, it's necessary to spend some thoughtful time up front. if I'm going to commit to a long project, it makes sense to choose it wisely. But assessing the capabilities for endurance on a long project is no trivial task. Computer scientist Edsger Dijkstra, known for numerous brilliant essays, suggested that the right project should have the following three characteristics.
First, choose a project in which you can 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."
Next, as to the specific project to choose: "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."
While Dijkstra was talking about scientific projects, it's not difficult to map this last injunction to programming projects.
And finally, the rule that probably most applies to OSS in the context of the previous discussion: "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."
This recommendation, perhaps more than any other, should be the guiding principle. It requires imagination, an understanding of one's own strengths and weaknesses, and some search of available solutions. When we look at OSS projects that were brilliantly successful, they were especially aligned to this guideline. As Dijkstra himself observed, "If others will come up with as good a solution as you could obtain, the world doesn't lose 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. The third rule ensures that your contributions — if any! — will be unique."
For many developers, these rules might be too stringent. There is a lot of personal empowerment felt by starting to grind away at a new IDE for your favorite language, even if you later abandon it. But if the goal is to create a project of lasting value, one that will keep you busy and satisfied for its duration, Dijkstra's prescription, in my view, is the best way to go.
— Andrew Binstock
Editor in Chief
alb@drdobbs.com
Twitter: platypusguy
