Archivi tag: linus torvalds

The Cathedral & the Bazaar – III

Posted on by

The 3rd part is about parallelization of development and design. The
ingredients of this recipe are users, maintainer and a promise!

The Promise: run and convince
To crowd people have to be promising, but not perfect.
It should just: run and convice potential co-developers that it
can be evolved in a near future. Design is fundamental for convince ;P

The Community
10. If you treat your beta-testers as if they’re your most valuable
resource, they will respond by becoming your most valuable resource.

They’ll send great bug reports and your list will populate.
It can happen too that the sw is so stable that people will
unsubscribe the list ;)

The Maintainer
11. The next best thing to having good ideas is recognizing good ideas
from your users. Sometimes the latter is better.

A significant improvement in fetchmail have been given by a user idea:

a fundamental skill is to

  • understand when to leave his ideas for a user one,
  • and recognize good design.

Linus talent was not to be a great programmer but to pick good design
choiches from community.

12. Often, the most striking and innovative solutions come from
realizing that your concept of the problem was wrong.

Many users provide many environments for your sw, so they could
provide you many point of views and… DESIGN!

Like debugging Exploration of Design Space scales almost linearly:
like ants look for food you’ll get new design ideas from community.

And so a Saint-Exupéry quote:
13. “Perfection (in design) is achieved not when there is nothing
more to add, but rather when there is nothing more to take away.”

The Cathedral & the Bazaar – I

Posted on by

Since now, I’ll post some extracts from the nice “The Cathedral & the Bazaar”, the book by ESR which describes the differences between the development process of open and close software.

The diffences derive from opposing assumptions about the nature of debugging. Open way states “given enough eyeballs, all bugs are shallow”.

Linus’ style was release early&often, delegate as possible, be open until promiscuity.

1. Every good work of software starts by scratching a developer’s personal itch.
This explain the average good quality of floss.

2. Good programmers know what to write. Great ones know what to rewrite (and reuse).
Their constructive laziness knows that you get an A for your result, not for your effort.

3. “Plan to throw one [software] away; you will, anyhow.”
You’ll usually learn how to write a software AFTER you’ve finished it: so be ready to start again.

4. If you have the right attitude, interesting problems will find you.
and
5. When you lose interest in a program, your last duty to it is to hand it off to a competent successor.

After you’ve been involved in a floss, you could become its maintainer; and when your interest ends, you must find an heir