Community Management Wiki


Bikeshedding involves discussions about relatively unimportant issues which result in extensive debate. It may be the result of individuals who wish to contribute feeling that they don't have the knowledge or expertise to contribute on more significant issues. Bikeshedding can result in discussions that, whilst on-topic, nevertheless effectively drown out other discussions on more significant issues. On the other hand, it also suggests that community leaders might need to consider how they can better assist and/or support those with less knowledge and expertise to contribute to the community in possibly more productive ways.

The origin of the phrase is a story from C. Northcote Parkinson in his 1957 book Parkinson's Law and Other Studies in Administration:

PEOPLE WHO understand high finance are of two kinds: those who have vast fortunes of their own and those who have nothing at all. To the actual millionaire a million dollars is something real and comprehensible. To the applied mathematician and the lecturer in economics (assuming both to be practically starving) a million dollars is at least as real as a thousand, they having never possessed either sum. But the world is full of people who fall between these two categories, knowing nothing of millions but well accustomed to think in thousands, and it is of these that finance committees are mostly comprised. The result is a phenomenon that has often been observed but never yet investigated. It might be termed the Law of Triviality. Briefly stated, it means that the time spent on any item of the agenda will be in inverse proportion to the sum involved.
Chairman: Item Ten. Bicycle shed for the use of the clerical staff. An estimate has been received from Messrs. Bodger and Woodworm, who undertake to complete the work for the sum of $2350. Plans and specification are before you, gentlemen.
Mr. Softleigh: Surely, Mr. Chairman, this sum is excessive. I note that the roof is to be of aluminum. Would not asbestos be cheaper?
Mr. Holdfast: I agree with Mr. Softleigh about the cost, but the roof should, in my opinion, be of galvanized iron. I incline to think that the shed could be built for $2000, or even less.
Mr. Daring: I would go further, Mr. Chairman. I question whether this shed is really necessary. We do too much for our staff as it is. They are never satisfied, that is the trouble. They will be wanting garages next.
Mr. Holdfast: No, I can’t support Mr. Daring on this occasion. I think that the shed is needed. It is a question of material and cost…
The debate is fairly launched. A sum of $2350 is well within everybody’s comprehension. Everyone can visualize a bicycle shed. Discussion goes on, therefore, for forty-five minutes, with the possible result of saving some $300. Members at length sit back with a feeling of achievement.

For further discussion, see Parkinson's Law of Triviality and Sayre's Law.


The canonical example which gave rise to the phrase in the free software world is from the BSD community, and is documented at

The thing which have triggered me this time is the "sleep(1) should do fractional seconds" thread, which have pestered our lives for many days now, it's probably already a couple of weeks, I can't even be bothered to check.
To those of you who have missed this particular thread: Congratulations.
It was a proposal to make sleep(1) DTRT if given a non-integer argument that set this particular grass-fire off. I'm not going to say anymore about it than that, because it is a much smaller item than one would expect from the length of the thread, and it has already received far more attention than some of the *problems* we have around here.
The sleep(1) saga is the most blatant example of a bike shed discussion we have had ever in FreeBSD. The proposal was well thought out, we would gain compatibility with OpenBSD and NetBSD, and still be fully compatible with any code anyone ever wrote.
Yet so many objections, proposals and changes were raised and launched that one would think the change would have plugged all the holes in swiss cheese or changed the taste of Coca Cola or something similar serious.


To many, diagnosis is the first step towards treatment. Simply by identifying a discussion as a "bike-shed", much of the energy that has been spent in the discussion can be dissipated. Problems arise when there is not agreement over whether something is a major consideration or a minor detail.

In general, the negative effects of bike-shedding can be mitigated by encouraging a community which rewards action. Two methods are suggested:

  • Encourage the proposer to provide an implementation of his proposal, having taken into account the most significant remarks
  • Propose a "bake-off" if there are competing philosophies. Often, only one implementation will follow.

According to Karl Fogel in Producing Open Source Software:

The best you can do is point out that the phenomenon exists, when you see it happening, and persuade the senior developers—the people whose posts carry the most weight—to drop their paintbrushes early, so at least they're not contributing to the noise. Bikeshed painting parties will never go away entirely, but you can make them shorter and less frequent by spreading an awareness of the phenomenon in the project's culture.

Related patterns[]

Bikeshed discussions result in decision paralysis.

They are often aggravated and frequent in communities which tend towards anarchy and an excessive egalitarian or "free speech" philosophy.

Repeated bikeshed discussions are a key factor in encouraging water cooler behaviour