Social Architecture: Building Online Communities by Pieter Hintjens

// Publicado em: 28 de março de 2023

https://hintjens.gitbooks.io/social-architecture

Preface – The Wisdom of Crowds

• Under the right circumstances, groups are remarkably intelligent, and are often smarter than the smartest people in them. (Wisdom of Crowds)
• Group of random people will on average be smarter than a few experts
• Adding more experts to an expert group will make it stupider, while adding normal people will make it smarter
• Social Architecture: building smart, self guiding, successful online communities that could beat expert groups every time
• Applications of patterns, psychology, economics, politics, humanism, technology and optimism
• Successful on-line communities are based on mutual benefit, implicit or explicit, meaning that we can build a billion dollar company with volunteer labor
• The crows should really wants to solve the problems you throw at it
• Elements necessary for a Wise Crowd
  • Diversity of opinion
  • Independence of members from one another
  • Decentralization
  • Effective ways to aggregate opinions
• People who are unemotional about their subject 🤔
• Having wise crowds is amazing, but why we still see the world filled with so much stupidity? Is the Wisdom of Crowds a theory that falls apart in practice? But we do have very successful online communities, so it must be true!
• Citizens of digital society choose freely which authorities to respect and which to ignore
• Intense competition to develop fair authority that does not command, true leadership
• We humans developed instincts for joining and conforming to groups in order to survive, that’s where cults get its peeps, exploiting these instincts
• Good groups are the reverse of Cults. Cult have principles like Removal of Privacy and, if we reverse it to Give private space to people think and they will become better at thinking, we are reversing cult principles
• Reversing the Cult is not enough. We need explicit patterns, like:
  • Powerful mission to attract newcomers
  • Make really easy for people to get involved
  • Embrace argument and conflict
  • Delete systematically, create competition
  • Work more with volunteers
  • Get diversity and scale
  • Make people own the work, and not the work own people

Chapter 1. The Toolbox

The 20 tools:

• Strong mission – the stated reason for the group’s existence
  • Clear mission, make people less confused
  • Change it over time to adjust to customers, as the community matures
  • Only when you have a clear and real problem that everyone agree, move to discussing solutions
• Free entry – how easy it is for people to join the group
  • After the mission, you need a seed: people (idealists and pioneers) and to prove or disprove the mission
  • Failure is fine, even excellent, unless it costs years of your life
  • The platform used to work needs to be free, easy to learn and accessible
  • Work with the idiots and critics, avoid “selection bias"
  • Never turn away anyone who wants to contribute, the community is more important than the product
• Transparency – how openly and publicly decisions are made
  • Groups that work in secret do not achieve wisdom
  • Digital society grows best by putting scale before profits, treating all ignorance as problem to solve
• Free contributors – how far people are paid to contribute
  • Every person is there for self-interested reasons
  • When you work for someone else, you will make what he or she wants. When you work for yourself, you will make what you need
  • You want contributors who are there for honest, transparent reasons
• Full remixability – how far contributors can remix each others’ work
  • “What is the copyright license on this work, and how does that affect the community?"
  • Prefer a “share-alike” license, two way remixing
• Strong protocols – how well the rules are written
  • Good protocols let strangers collaborate without up-front agreement
  • Good rules are simple, clear, explicit written down and agreed upon by all
  • Use a template from another community, or start small and grow as problems arise
  • Complex, confusing, ambiguous rules confuse people, cause conflict etc
• Fair authority – how well the rules are enforced
  • Without authority, rules have no strength
  • Authority usually is the founders and main contributors
  • Authority should scale as the group grows
  • Put active members into position of authority quickly, you may lose them to other projects
  • Authority must dogfood their own rules
• Non-tribalism – how far the group claims to own its participants
  • Members should include themselves into the group, and should not feel trapper inside it
  • Membership must NOT be exclusive – members can participate in other groups – otherwise it will cause conflicts with other groups
  • Members should be encouraged to experiment and even start a competitive project
  • Measuring: If response to a competitive project is negative and emotional, the group is tribal
• Self-organization – how far individuals can assign their own tasks
  • The best organisations allows contributors to choose and work on the tasks they want
  • You should accept contributions in any area, without limit
  • Hierarchies creates bureaucracy, long chain conversations, can’t scale rapidly
• Tolerance – how the group embraces conflicts
  • Embrace diversity and different opnions
  • Have rules or guides to deal with trolls, vandals, toxic people
  • Listen to all opinions, don’t turn them down just because you think they are “dangerous”, you’ll end up suppressing new ideas
  • When there’s a new problem, try to get different teams working on it, it can be fun and yield better solutions than monopolised problems
• Measurable success – how well the group can measure its progress
  • Well, have a way to measure, like forks, stars, contributions, issues opened/closed
• High scoring – how the group rewards its participants
  • Overriding motivation is to be admired for success, as an individual or as a team
  • Extreme gamification can be bad. People should be contributing for the success of the project, not for play points
  • Look into some kind of social credit (making groups of strangers happy)
• Decentralization – how widely the group is spread out
  • Be diverse, centralisation means biases, common triggers, exclusion
  • Meetings to get stuff done means excluding the ones that cannot participate
• Free workspaces – how easy it is to create new project
  • Make it easy for people to create new spaces, projects
  • Have a guideline to how bring these projects into the official structure
  • Embrace some level of chaos
• Smooth learning – how easy it is to get started and keep learning
  • Community as a video game, make it easier to start and progress difficulty just as people get more expert level contributors
  • Classic training tools to get people started: presentations, videos, FAQ, tutorials
• Regular structure – how regular and predictable the overall structure is
  • Avoid large complex structures and projects
  • Strive to have very wide structures (projects), sharing their basic structure as much as possible, strive to have predictable units of structure
  • Think about cities, not castles
• Positivity – how far the group is driven by positive goals
  • Be positive from the start, avoid hostility, hate, heated arguments
  • Find positivity from every input, like competitors, copycats, trolls etc… all of these experiences can improve the positivity and honesty of a community
  • Positive culture reduces emotions, arguments, makes easier to experiment, fail and self-criticize
• Sense of humor – how seriously the group takes itself
  • A shared joke can create bounds because it proves the intersection of minds
  • Humor reduces stress
  • Insert funny, small nonsenses into technical explanations
  • Lack of humor is a sign that everyone is fundamentally miserable
• Minimalism – how much excess work the group does
  • Be dogmatically minimalist about the work you do, it will make the community lighter and faster
  • Do absolute minimum that probably works
  • User feedback is the best guide for where to make further investments
  • Buggy, half finished work attracts contributors, perfection attracts users
• Sane funding – how the group survives economically
  • Not enough money, the community will starve. Too much money, it will rot.
  • Spend money only when necessary. Instead of investing money, can someone help?
  • Watch for peeps who take too much risks without enough rewards, they can burnout

What do do:

• Consume your own product
• Practice and repeat: cheap to experiment, failure Is healthy, start as many projects
• First line support, observe new visitors, see their mistakes, adjust
• Release early, release often
• Learn and teach all the time

Chapter 2. Sidebars

Another topics worth discussing.

Market Curve

How different types of people join your project at different periods of time. This is not hard science, and can overlap, but usually happens like this:

• With a young and experimental project, you’ll attract researchers and curious. Their business is to explore new stuff. They won’t contribute nor last too long. They are your evangelists.
• With a seed projects, pioneers will come. They are hackers not afraid to try something, without necessity to have documentation, tutorials etc. First wave of contributors.
• With a usable product, comes the early adopters. People good at managing risks, building products and projects with your project. They don’t need help, but expect some stability. Bulk of the community.
• With a stablished and stable product, comes the mass market. They expect stability, and will ask for support. They are usually the paying customers.
• Later versions you’ll have the skeptics trying out new stuff.

Volunteer Burnout

Volunteer work is amazing, but it can lead to burnout of not well managed. It manifests in the community a per project basis, when someone suddenly perceives the project as toxic and leaves. It takes some time to get there, but it’s curable and preventable.

People usually invest their time – thus, their economy – in projects because somehow they feel it’s gonna be good for then, it will propel them somewhere or it’s an investment that will pay off at some point in time. These people will burn out if they think that all the effort they’ve put into the project was a wast of time, that the mission statement is a lie, the praise was fake etc etc. People will quit.

You can avoid this by not letting people work alone in the product, having a business plan (roadmap, process), preventative education in burnout and good tools and processes that let people work if less dependency of any one other person.

The Myth of Individual Intelligence

Less experts group of people are way more intelligent than a group of experts. The Internet being a good example as a project created by lots and lots of smart people, through RFCs that anyone could improve and open source software that anyone could remix.

• Individual creativity matters less than process
• Roadmaps are unnecessary if they are good processes
• We don’t invent solutions as much as we discover then
• Intelligence is a social factor, cut people out of their communities and they will stop thinking
• Bigger and diverse communities will yield better problem finding and better accurate results

How to Capture an Open Source Project

A section about the possibility of Google capturing Android into a closed source software. Basically, you release an open source project into a market with a lot of unsatisfied users, let them use, improve and become dependent on it. When the software/product is established, you slowly “Capture the Flag” by closing the product little by little.

Needless to say, that’s awful shit. Decision made out of self interest and low sense of ethics.

We can avoid these by using a “share-alike” license and have a contribution policy (who owns the contributions made to the project?).

Licenses:

• Closed. Basically copyright.
• Free to take: one way remixing, people can do whatever they wan’t if the project without any consequences. Apache, BSD, MIT.
• Share-alike: enforces two way remixing, people can grab your project and do whatever they want, but you can them grab their project and do whatever you want. GPL, LGPL and cc-by-sa.

Contribution policy: Who owns the project? Can it be bought? Do I need agreement through the whole contributors to be able to sell it?

Wanna be cool? Go with share-alike and distributed copyright.

Trademarks

A whole thing about trademarks. Not much to take notes on. Buy it if you really need kinda stuff 🤷‍♀️

Chapter 3. The ZeroMQ Community

• LGPL License
• Core software is libzmq and other community projects (bindings) and implementations
• Everything is in the GitHub org, run by a group of the most senior binding authors, very self-managing, zero conflict
• iMatix is a company with a role in the community: to own and enforce the trademarks
• ZeroMQ is for-profit project
• The original ZeroMQ white paper had two projects: a technical one and a community one
• Software dies, but community survives
• Two ways to make large-scale software: throw a shit load of money on it OR make it open source (free software)
• You can deliberately grow a free software community, not a hard science, but possible

Psychology of Software Architecture

• Software is about people
• Large structures are meaningless if humans can’t use them
• The core problems in software architecture are drive by human psychology, not technology
• ZeroMQ community came from Social Architecture, which means the process and the product of planning, designing and growing an online community
• How we organize is more significant than who we are
• Ordinary people well connected can outperform experts using poor patterns
• We are really bad at understanding complexity but good to work together to divide and conquer large problems
• The List of Psychological Elements of Software Architecture
  • Stupidity: the architecture MUST be simple, we have limited amount of energy and become stupid at some point. If you can’t understand it in ur worst days, you are failing. Simplicity beats functionality, always!
  • Selfishness: people have their own self interest and the architecture should create the space for people to satisfy their self interest but also benefit the whole
  • Laziness: happiest when u get a result when applying the least effort. It must be simple
  • Jealousy: we will overcome our stupidity and laziness when trying to beat other people in competition. The architecture should allow for public competition based on fair rules that anyone can understand
  • Fear: the architecture should give people a safe space for silent experimentation, celebrating achievements and without punishing failure
  • Reciprocity: the architecture should have well established and enforced rules, telling people how to work together, but not what to do
  • Conformity: if the right path is the easiest path, we will choose the right path every time
  • Pride: we are always aware of our social status, the architecture must make sure that our name is on every piece we make
  • Greed: we are economic animals – the architecture should give us economic incentive, could be polishing our reputation as experts, making money from some skill… think of architecture as a market place, not an engineering design

The Importance of Contracts

• “We are not really angels, nor devils, just self-interested winners descended from a billion-year unbroken line of winners”
• In everything, projects, marriages, jobs, contracts: sooner or later, we stop caring or with argue and argue.
• We either have a project that’s a failure where no one cares, or something relevant and valuable, which makes us start to care about power, control and money.
• Licenses can be seem as contracts to protect the relationship of the individuals inside and outside of the project.
• “Which license will attract more contributors?” is an invalid question, the mission statement and contribution guidelines should answer that. The better questions are: “we we had a big fight and split the group in two, which license would save us?” or “we a firm employed all the core contributors and want to make the project closed source, which license would save us?"
• GPL’s, the share-alike, is the author’s favorite license for software projects.

The Process

• Goal as a community leader:
  • Motivate people to go out there and explore
  • Ensure they can explore safely without disturbing others
  • Reward them when they make successful discoveries
  • Ensure they share they knowledge (not because they want, because it’s the LAW)
• You need a goal that’s crazy and simple enough to make people get out of the bed in the morning
• Contributors are users who wants to explore a little bit more from where you are right now
• If you solve even a small problem that people didn’t realize they have, you’ll have a bit of their soul
• It must be easy to understand and easy to join
• Diversity beats education any time
• You need an a set of rules and a platform that allows two strangers to work together without even meeting each other before
• The C4 rulebook controls how work actually happens
• Enforce transparency, it’s essential to get trust, don’t let people work with secrets in the corners because “is faster"
• The rules must apply to everyone, don’t be the “I founded this project thus I’m smarter then you" leader
• Ideas are cheap, what makes valuable property is the hard work to build a market

Care and Feeding

• You need some form of symbolic leadership, to resolve conflicts that no one can, because people are just too nice
• A community needs living rules. When done right, they remove friction, whey done wrong, they add friction and drive the majority crazy
• You will need some money. No money and you burn out contributors. Too much and you attract professionals killing diversity and creativity. Share pool of money and people will fight over it.
• Sales and commercial mediation is important. Try to get your best contributors as consultants, for example. Connect the experts with the customers.

Chapter 4. The ZeroMQ Process: C4

• A study on C4, an evolution of the Fork + Pull Model of Github
  • There’s a lot about opening issues, pull requests, forks etc
• Behind the RFC 2119 Language (MUST, SHALL, SHOULD etc)
• In my opinion is very good rule book with lots of common sense, enforced as rules, which is great
• They are some stuff that was outstanding for me, tho, here they are:
  • Focus on well being of the community more than product
  • Lowers the entry of new members to the community
  • Tries to make the project development faster and more assertive
  • Provides safe space to allow safe experimentation, rapid failure
  • Tries to achieve collective ownership of the project
• All patches are owned by the contributors
• Always use some GPL license
• The contributors are responsible for inserting themselves in the CONTRIBUTORS list (wanna karma points, go get it!)
• Usage of real names or well-known alias
• Simplicity everywhere: patches should be simple, solve one problem
• MUST HAVE A CODE GUIDELINE!
• There should be a Public Contract that determines how public APIs evolve, retire etc
  • Public contracts should evolve with code
  • Public contracts should be documented, DON’T expect people to understand the contract from the code!
  • Public contract should have space for extensibility and experimentation
  • Patch should not break existing contract unless everyone agrees to or there’s an enormes amount of value
  • Older contracts should be deprecated
  • Old names SHALL NOT be used in new features, don’t confuse people
  • Contracts must be deprecated systematically
• Propose an issue before proposing a solution (or seeking for one), issue before PR
• Users SHALL NOT log feature requests, ideas, suggestions etc. They should log a PROBLEM and a possible SOLUTION
• Maintainers SHALL NOT accept their own patches, forces maintainers to work with other people and to not break the rules
• Maintainers should judge the patch technically and not in their value system (this works VS I don’t like this)
• Maintainers should merge correct patches rapidly, this makes users feel they accomplished something and make them contribute more. No ones likes a issue/PR that stays there for days and days without attention
• Don’t Do Pessimistic Merging (industry default)
  • PM is when it follows the cycle of test/review too many times, when the maintainer becomes pick with stuff
  • Avoid “guilty until proven innocent” patches, creating negative emotions
  • Avoid maintainers showing that they have more power than others
  • Avoid putting the burden in the contributor alone, help them!
  • This avoid long, picky discussions with a lot of up front work and energy that could be spend on iteratively improvements
• Do Optimistic Merging!
  • Join the contributor if the patch doesn’t seem ready, show that you care and would like to help
  • Merge mediocre code. If it is import someone will come and fix it, or, if no one cares, someone will remove it
  • Merge toxic code, it will reverted immediately by someone/contributor
• Users should clone their own issues, give the users a sense of finished work
• Maintainers should close issues left open without action for some time, keep stuff clean
• Master should always work and be the release base
• Release always on tags
• Founders shall behave like administrators to keep the project rolling
• Promote good maintainers to take over the project
• A new contributor who makes correct patches, understands the code the mission, the goals should be invited to be a maintainer ASAP!!!
• Have a policy to remove inactive Maintainers, crop the noise
• Ban bad actors, someone that repeatedly broken the rules, but do this openly and publicly, allowing the actor to defend themselves

Chapter 5. Designing for Innovation

• Solving problems more cheaply
• Bad aspects of road maps
  • It’s hard to deliver promised stuff
  • Hard to get volunteer contributors to commit to a roadmap
  • Shift of priorities overtime
  • “Claiming territory” making it harder for other people to work on what they would like to work… makes an opportunity to contribute into a chore
• What to do instead of roadmap?
  • Good process
  • Working on what is important right now, something that has proven to be needed by someone

Trash-Oriented Design (TOD)

• “What makes money are great ideas”
• The output of TOD is expensive ideation: concepts, design docs etc
• Process:
  • Someone has a great idea
  • Managers get designers to come if all the idea specs
  • Outputs are delivered to engineers who are forced to implement it, arguing is not an option
  • Something like a product is release after a lot of work
  • No one buys the product, no one actually cared
  • A lot of money is thrown at the product marketing
  • Maybe it will pick up, probably it will be a failure
• Main lessons:
  • Ideas are cheap. Hard work is not
  • Design should start with real problems that confront real people
  • Good solutions to real problems will be successful products

Complexity-Oriented Design (COD)

• Solving real problems with overly complex products
• People forget to ask “What is the real value of solving X?"
• Process:
  • Management finds a real problem to solve
  • After intense design and architecture, people start building the core product
  • Management comes back with more harder and expensive problems (they think that if a problem is expensive is worth solving it)
  • People build more and more stuff, perfectly-designed complexity
  • Product goes to market, people use because there’s nothing else, but think it’s too complex
  • Loop continues
  • Meanwhile some other place in earth someone solves the same problem with a better process and destroys the market
• Main lessons:
  • Making stuff that you don’t immediately have a need for is pointless
  • Solving the simpler problems has more value that solving the really hard ones
  • Engineers and Designers love to make stuff, to the point of getting very complex.. have a stop mechanism to force people to work on the crucial problems with smaller, simples answers

Simplicity Oriented Design (SOD) – a hill climbing algorithm

• “We do not know what we have to make until after we start making it"
• Design is about removing friction in the use of a product
• Process:
  • Collect a set of interesting problems (by LOOKING at how the users are using the product), from simple to complex
  • Get the simplest and most dramatic problem and solve it with a minimal plausible solution
  • Ask the question: can this be done simpler? A perfect solution requires zero learning curve from the User
  • The minimal solution is a PoC that evolves in a mature product, with thousands of patches
  • Everything is a patch, every patch needs a documented genuine problem
  • Individuals are free to work the way they want in the project
  • Projects have formal and documented interfaces
  • Work in a rapid cycle of users’ problems the can be analysed, evaluated and solved
  • The product is shippable ALL the time, since its first patch

Burnout: too much investment in a project with too little economic rewards for too long

• In volunteer work we sacrifice family time, leisure, free time, money to accomplish an objective
• We are economic creatures, we need economic rewards (money, fame, new job)
• If we don’t get any reward, we burn out
• Reducing the risk:
  • No one should be irreplaceable
  • We need normal jobs to pay the bills
  • Teach people about burn out

Chapter 6. Living Systems

See book.