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 ï¬x 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