Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Channels ▼


Dijkstra's 3 Rules For Project Selection: Picking Useful, Unique Projects

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
[email protected]
Twitter: platypusguy

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.