Archivi tag: opensource

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 – II

Posted on by

This second session is about scaling your community and improve debugging.

6. Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.
Managing a floss is not just coding, but growing the community. This was Linus’ real goal.

An interesting thing is that you can use a two-tier user community combining the old cathedral-mode with the bazaar one: this is done by Matlab (cathedral core, bazaar plugins)

7. Release early. Release often. And listen to your customers.
and
10. If you treat your beta-testers as if they’re your most valuable resource, they will respond by becoming your most valuable resource.

in floss your customers are your users too. So, accept contribution and involve people: if the contribution is bad it will be fixed as quickly as your community grows.
In that way Linus stimulated constantly his users/hackers!

8. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.
aka
8.bis Debugging is parallelizable
While developing effort is o(2) [Brook’s law], debug effort is o(1), so the more testers you have, the better. Moreover you’ll save developers’ time!

9. Smart data structures and dumb code works a lot better than the other way around.
9.bis Show me your tables, and I won’t usually need your flowchart; it’ll be obvious.
Better data structures means faster communication between team and testers

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

The power of Twitter

Posted on by

Ultimamente visto che non ho più un vasto pubblico ( vedi openspace AST ) mi sono rivolto a twitter per regalare al mondo le mie assurde esclamazioni.

Oggi dopo un accesa discussione sulle basi della sicronizzazione dei dispositivi mobili ( soprattutto tramite ssl ) insieme a due dico due consulenti certificati microsoft ( tra cui uno ha fatto pure  il corso aggiuntivo per  l’unified messaging ), ho meditato  su quante cose ho visto grazie a funambol ed ho scritto il seguente post su twitter.

tweet

Una volta tornato a casa apro il portatile e noto qualcosa di strano all’interno della timeline di gwibber

gwibber

Non ci posso credere … Fabrizio Capobianco in persona … cioè il capo di funambol fà un bel reply su al primo fannullone ( per non dire di peggio ) di turno che fa un esclamazione attraverso twitter  …  mica mi vorra citare in tribunale per il sync ’em all ?

Screenshot della pagina twitter del Capo di Funambol

fabricapo

Morale della favola ? …. beh nessuna ! Questo evidenzia come anche il primo “fannullone” che passa oggi ha i suoi 45 secondi di notorietà come prevedeva Handy Wharrol.

Per finire  questo lagnosissimo post e da un po che mi pongo la seguente domanda ma perchè  di ogni componente o servizio con cui abbiamo a che fare lo conosciamo in modo così viscerale ?  Solo perchè andiamo una spada?

Aspetto impaziente un vostro commento.