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
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 ;)
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.â€
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.
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 ï¬x obvious to someone.
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 ï¬‚owchart; itâ€™ll be obvious.
Better data structures means faster communication between team and testers
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 ï¬nd you.
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
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.
Una volta tornato a casa apro il portatile e noto qualcosa di strano all’interno della timeline di 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
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.