The Cathedral and the Bazaar

[AdamWargon]

I was on an urbanism call earlier, and someone threw out this expression as if we should recognize it. But I had never heard it before!

The Cathedral and the Bazaar comes from an essay written in 1997 by Eric Raymond.

It contains some tips for developing open-source software. Which best practices do you recognize in iNat?

Lessons for creating good open source software

Raymond points to 19 lessons learned from various software development efforts, each describing attributes associated with good practice in open source software development:

1. Every good work of software starts by scratching a developer’s personal itch.
2. Good programmers know what to write. Great ones know what to rewrite (and reuse).
3. Plan to throw one [version] away; you will, anyhow (copied from Frederick Brooks’s The Mythical Man-Month).
4. If you have the right attitude, interesting problems will find you.
5. When you lose interest in a program, your last duty to it is to hand it off to a competent successor.
6. Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.
7. Release early. Release often. And listen to your customers.
8. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.
9. Smart data structures and dumb code works a lot better than the other way around.
10. If you treat your beta-testers as if they’re your most valuable resource, they will respond by becoming your most valuable resource.
11. The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better.
12. Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong.
13. Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away. (Attributed to Antoine de Saint-Exupéry)
14. Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected.
15. When writing gateway software of any kind, take pains to disturb the data stream as little as possible—and never throw away information unless the recipient forces you to!
16. When your language is nowhere near Turing-complete, syntactic sugar can be your friend.
17. A security system is only as secure as its secret. Beware of pseudo-secrets.
18. To solve an interesting problem, start by finding a problem that is interesting to you.
19. Provided the development coordinator has a communications medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one.

[tf1]

When I was a young FOSS (free and open source software) contributor in the early 00s, this seemed like a really profound stuff; quarter a century later, it’s not aged so well for me.

One thing I learnt very quickly is that the intersection of ‘developer itches’ and ‘real world problems’ is in fact rather small, and it doesn’t scale as model; software that is built by scratching developer itches doesn’t do anything else than scratch those few itches.

He also badly overestimates the benefits of the many eyeballs; in practice in most FOSS projects the lion share of work is done by a very small core team, the theoretical access to unlimited contributors has only limited benefit to the project; indeed, at times dealing with poor quality contricutions can be detrimental, to both the project and the individuals.

Also no real FOSS projects are run as a genuine bazzar, certainly not the Linux kernel; indeed the kernel ‘community’ has some pretty toxic history. Bazzars tend to organically generate ‘meritorcracies’, but we have learnt that ‘meritocracies’ are often more about conscious and unconscious biases than actual merit. And so most big FOSS projects now have Codes of Conduct, the enforecement of which requires formal structures, etc.

But I think the most important thing we learnt in those 25 years is that active unpaid FOSS developers suffer from a very high level of burnout, and when they do, projects die, at this point handover is not an option, burnout is not simply the loss of interest (the gift economy doesn’t work for software, there is an aweful lot corporare taking without any giving).

There is undoubtedly loads that any crowd-sourcing project can learn from FOSS, but we have learnt loads about the dynamics of distributed communities since the 90s.

[DianaStuder]

@AdamWargon

never throw away information

which is why @jeanphilippeb and @rogue_biologist built the Placeholder Backup Project (to answer my request). We have almost 5K obs where the placeholder would have been destroyed.