3. About you
● You're a programmer, organizer, leader
● You want to make successful software
● You want to work with other people
● You want to change the world
● You want to earn your living
4. About me
● “Pister Hinges”, origins unclear
● My code is crappy, my music is worse
● My businesses are lousy investments
● My protocols are clumsy (sorry for AMQP)
● I still can't believe O'Reilly published my book
● If failure is a university, I have many PhDs
6. Let me tell you a story...
● Closed source is Dead on Arrival
● The future belongs to open source
● To make open source, build communities
● There is a science to it: “Social Architecture”
● It can be very profitable
8. Our industry sucks
● All our effort goes to making stuff
● Mostly stuff no-one really wants
● Missing every new opportunity
● Constant build-up of technical debt
● Complex, irrelevant, trash
10. Imagine a Perfect World
● Community does most of the work
● Mostly, things people really want
● Rapid colonization of new spaces
● Constant pruning of technical debt
● Simple, elegant, precious
12. Why is accuracy so difficult?
● We love to make grand designs
● But problems are emergent
– I.e. we see them only when we get close
● Speculative design makes us blind
● Upfront structure makes us slow
● We attach to solutions, not problems
14. Simplicity Oriented Design
● Design by removing problems, not adding
features
● Simplicity beats functionality, every time
● Discover the core problems
● Solve them minimally
● Use that to discover next set of problems
● Aka “Drunken Stumble”
15. Why open source?
● Open source lets us make more accurate,
simpler software
● In a free & fair market, this will win
● Open source can be very profitable
– Profits are widely spread
● It's a social technology
– Not a business model
16. Why communities?
● No-one wants to live in Astana
● Community over code
● Community grows with the code
● We build the code
● We own it and look after it
18. Social Architecture
● “The art and science of growing an online
community”
● Cultural, political, or technological
● How we organize beats who we are
● Simplicity beats functionality
● Diversity beats education
20. We're a funny animal
● We're lazy and stupid, so keep it simple
● We're selfish, so make it worth our while
● We like to conform, so give us good rules
● We're greedy, so make us compete
● We're fearful, so make it safe for us fail
22. How social is your code?
● An open source license is the contract on which
the community forms
● The license defines economics of behaviour
● A good contract dissolves conflict
● Type 1: BSD (MIT, X11, Apache, ...)
● Type 2: GPL (LGPL, AGPL, ...)
23. The essence of BSD
● The BSD license says, "Eat Me!"
● Some community building
● Significant leakage
● Mixable but forks are endothermic
● Ideal for large groups to dump code
24. The essence of GPL
● The GPL says, "Remix Me!"
● Strong community building
● Minimal leakage
● Remixable, forks are exothermic
● Ideal for the revolutionary
26. Start small, grow slowly
● Make seed product at own cost
● Do this in public view
● Pull in pioneer contributors
● Community designs next iteration
● Repeat ad infinitum
27. The community life cycle
● Pioneers, hunting for new stuff
● Leading edge, becoming specialists
● Early adopters, looking for profit
● Mass market, avoiding risk
● Late adopters, just keeping up
29. Crazy and beautiful
● A crazy, impossible mission statement
● Has to speak to pioneers and leading edge
● Simple, elegant, brutally clean
● Has to be immediately useful and compelling
● You want love at first sight
30. Ease of access
● Remove all barriers to getting involved
● If you're not using GitHub, you should be
● Has to work for early adopters
● Aim for diversity of participants
● Origin, gender, age, experience
32. Stranger, meet Stranger
● Eliminate need for up-front agreement
● Invest in really good rules
● Apply the rules transparently and fairly
● Founder becomes enforcer of fair rules
● Not some special genius visionary
33. The C4 rulekit
● Plug and play rules for open source projects
● Focuses on scale of community
● Best practice from ZeroMQ community
● Codified for reuse by other projects
● ZeroMQ RFC 22 (rfc.zeromq.org/spec:22)
34. Infinite property
● Ideas are cheap and mean nothing
● Success comes from very hard work
● Participants should own their work
● Must be trivial to create new projects
● Scale by more projects, not bigger ones
36. Care and feeding
● Communities are not 100% self-steering
● They need an authority (founders)
● They need living rules (lawyers)
● They need sound economics (backers)
● They need mediation (clients to experts)
38. Communities gone bad
● Bitter fights over vision and direction
● Politics instead of real work
● Endless talk of angels and unicorns
● Fragmentation and emotional pan
● Mental abuse and burnout
40. Communities done right
● Consensus emerges quietly in real time
● No politics, focus is on real work
● Remarkably little upfront discussion
● Emotional talk is the exception
● Participants come and go easily
42. Immunity from capture
● Juicy projects attract predators
● Founders, investors, or 3rd parties
● See this from the community's view
● Does the license make us immune?
● Can we choose another authority?
44. Making money from open source
● Forget dual licensing & support
– Eating the seeds for tomorrow's crops
● Bring the cost down to zero
● Destroy your competition
● Standardize to create new markets
● Sell new stuff into those markets
45.
46. Hope you liked the story
● Read more at hintjens.com
● Buy the O'Reilly ZeroMQ book
Photos (c) 2013 Pieter Hintjens, shot in
New York city, Brussels, Vienna, a field in
France, and Berlin.
