The Prototype and the Fan Club Somebody creates a prototype, and a fan club forms around it "We reject kings, presidents and voting. We believe in rough consensus and running code" - David Clark, IETF Why attract a fan club: - bug reports and end user feedback. - Makes your "personal itch" tool better. - word of mouth advertising - Eventually recruit additional developers, but takes a while. - Worse conversion rate than PBS. You probably won't see 1% of your users contributing even bug reports, let alone patches or feature enhancements. - Complaints are feedback. It means somebody's using your stuff, which is inherently a compliment. Fix the complaint, make them happy. (Ok, less unhappy.) Prototype - Prototype must come first, before website, mailing list, design documents, etc. - code begets code, talk begets talk - Provide condensation nuclei for more code to organize itself around - provides focus: one point to the wedge - Grounds out discussion into "rough consensus and running code" - Must start small and simple, enough to demonstrate the viability of an idea - Lowest posible barrier to entry. - By the time it's hard to learn, there should be people to explain it. - Also design verified/adjusted to work, obvious functional holes filled in, reasonably tested/debugged. - maintainer's resume: why you should use my version, submit patches to me. - Hobbyists: unpaid, self-organizing meritocracy. - This is nothing new. (SF Fandom: first Worldcon held in 1930's.) - Forward reference 3 waves: hobbyist, employee, bureaucrat - Having written the program you use is the source of their authority. - Just coming up with an _idea_ isn't good enough. "No matter how good the idea, execution is everything" - Neil Gaiman - He's not a programmer, he's an author. Releasing open source is publishing a Fanzine - Releasing open source software is a publishing task. - Editorial job of maintainer: fight off sturgeon's law - "A maintainer's job is to say no" - Alan Cox - unsolicited patches form a slush pile - Sort through "reading slush", select entries (rejecting most) - polish if have time, or bounce back with comments. - stitch together selections into something vaguely coherent - release next issue - rinse repeat. - Maintainer has veto power only - Bounce back negotiation - Rejection letters, "the encouraging no" vs form letters vs ignoring you. - A personalized rejection letter is GOOD. - The guided veto, maintainer's leverage. "Here's what I would accept." - Hope patch gets rewritten, but push too hard and they'll walk. - Acts as architect, sets direction for project - Says what product does _not_ do. Need boundaries. Leading vs coordinating. - Ownership vs attribution. - Listening vs vision - Be aware of what users want, then do the right thing. - Want vs need. Hard. - Source of authority, reputation as currency - Brownie points. Spending them vs investing them. - Respect as currency: Peer review, peer acclaim. - can't call yourself a master - Highest accolade is to be known by name, not title. Linus's job title is "Linus". That's rock start status. - Richard Stallman, riches to rags. (Eric Raymond to a lesser extent.) - Linus is the Warren Buffet of brownie points. Hardly ever spends any, and when he does he invests them for a good return. Scaling - Initially the fan club just provides feedback - bug reports and design complaints - Maintainer generally remains primary author for some time. - Often no mailing list, just personal email and a blog. - May use an existing list (comp.os.minix, uclibc@uclibc.org) - Maintainer adds editorial tasks until they no longer have _time_ to code. - But must be _able_ to code, very well, or can't do the job. - Grow developers, add layers (user, dev, maintainer, lieutenant, architect) - Transition to an architect role. Write less code, but determine project's scope and direction. - Adding a hierarchy to not ignore, owed a response at some level. - Much better tools these days - Distributed source control (git and hg) can marshall patch _sets_. - Constantly re-sync diverging trees. - Tool to rebase and collate patch sets automates away 90% of work. - Ease integration of development branches (short-term forks) - Fork divergence: xemacs/emacs, BSDs. Licensing impact. Fighting off Sturgeon's Law as a business model - Distros do this. Red Hat/Ubuntu/Gentoo publish package anthologies. - Google does it for the internet. (SOEMBODY needs to for youtube.) - Aggregators (slashdot/fark) do it for news items. - Some mix aggregating with original reporting (lwn.net) - Filter existing content. How do you filter? By rejecting bad stuff. - Polish up what's left (if only with a clever fark headline) - Release early, release often. Importance of using current versions - Busybox FAQ - release early, release often - scheduled releases (video, time-based releases) - re-certify it's being maintained - If no release in a year, how long until my patch shows up in a release? - Live code vs dead code (beep, uClibc) - Why divergence between devel and stable is bad. Patch pressure - project gravity, absorbency - Why Linux killed the Minix development commmunity - grouonded out unusually high patch pressure - impermeable, patches bounce off, find a home in new forks or die off. - XFree86.org, grew too insular, forked. - Friction (Minix book deal, FSF copyright assignment, Patch penguin.) - Copyright assignment creates artificial friction. Bad. - Note about the FSF in the 80's, athena.ai.mit.edu Failure modes: - Bloated hairball, never say no. (Mozilla.) - Corporations new to open source, "but this code is free!" - Big codebase, small community. - Venerable rat's nest (XFree86, xmms) - High barriers to entry to new developers - Corporations taking a dump on the community. - Code with ripped out bits for IP reasons. Doesn't work. (Netscape, java) - Abandonware - Trailing source release - Release stale code - Wholly owned subsidiary - What's best for project vs best for company - Fedora year 1 IRC, year 5 "no foundation" - Copyright assignment Growing new developers: - From users. Don't use it, won't do anything else with it. - Intimately familiar with what it needs to do. - Bug report. - ask questions, make suggestions - small toe-dipping patches. (Spelling fix in comments.) - You just read the documentation: fix the docs. - Ripping some area of the code a new one. - domain expertise, ownership. I wrote that bit, I fix it if it breaks. - Lots fo code not accepted if developer won't stick around to fix it if needed. - Subsystem maintainer - Lieutenant - Inherit "maintainer" editor/architect position. - Or start own project. Lone wolf vs community - Not Invented here - code "smells like me". Must refactor to understand. - Is churn worth improvement? - Writing code is easy. Reading code is hard. - Impedence matching mental model to code on screen. - When writing, mental model leads. When reading, mental model trails. - This is why Perl is evil. Optimizes for the wrong thing. - Maintainer must let some code smell like other people to delegate and scale project. Must be very good at reading other people's code. Must be _comfortable_ with other people's code. - Are you the bottleneck? - Other people are smart too.