# Pieter Hintjens - Social Architecture (Highlights)  ## Metadata **Review**:: [readwise.io](https://readwise.io/bookreview/56742709) **Source**:: #from/readwise #from/reader **Zettel**:: #zettel/fleeting **Status**:: #x **Authors**:: [[Pieter Hintjens]] **Full Title**:: Social Architecture **Category**:: #articles #readwise/articles **Category Icon**:: 📰 **Document Tags**:: #favorite **URL**:: [hintjens.wdfiles.com](https://hintjens.wdfiles.com/local--files/books/social-architecture.pdf) **Host**:: [[hintjens.wdfiles.com]] **Highlighted**:: [[2025-12-12]] **Created**:: [[2025-12-13]] ## Highlights - Surowiecki identified four elements necessary for a wise crowd: diversity of opinion, independence of members from one another, decentralization, and effective ways to aggregate opinions. ([View Highlight](https://read.readwise.io/read/01kc14sdd36r72tqd5pgjc58r2)) ^965048088 - He describes the ideal wise crowd as consisting of many independently minded individuals who are loosely connected, who are geographically and socially diverse, who are unemotional about their subject, who each have many sources of information, and who have some way to bring their individual judgments together into a collective decision. ([View Highlight](https://read.readwise.io/read/01kc14teakqm51g6geejybvec2)) ^965048115 - The core trick is to accept authority without giving it the "right to command." ([View Highlight](https://read.readwise.io/read/01kc14xjbva0cwcnm7epchxqj6)) ^965048351 - Thus there is intense competition to develop fair authority that does not command, and instead enforces necessary rules. ([View Highlight](https://read.readwise.io/read/01kc14y1ab6dptmj2kgyr1c1bv)) ^965048365 - Strong mission -- the stated reason for the group's existence Free entry -- how easy it is for people to join the group Transparency -- how openly and publicly decisions are made Free contributors -- how far people are paid to contribute Full remixability -- how far contributors can remix each others' work Strong protocols -- how well the rules are written Fair authority -- how well the rules are enforced Non-tribalism -- how far the group claims to own its participants Self-organization -- how far individuals can assign their own tasks Tolerance -- how the group embraces conflicts Measurable success -- how well the group can measure its progress High scoring -- how the group rewards its participants Decentralization -- how widely the group is spread out Free workspaces -- how easy it is to create new projects Smooth learning -- how easy it is to get started and keep learning Regular structure -- how regular and predictable the overall structure is Positivity -- how far the group is driven by positive goals Sense of humor -- how seriously the group takes itself Minimalism -- how much excess work the group does Sane funding -- how the group survives economically ([View Highlight](https://read.readwise.io/read/01kc19kbw9v58va50n487q1m08)) ^965060597 - Consume your own product. If you are not a fanatical user of whatever your group is making, you are half-blind. ([View Highlight](https://read.readwise.io/read/01kc19m633s7qdjxk7339nh2b1)) ^965060796 - When proposing action, small or large, try always to start by identifying the problems you want to solve. Only when you have a clear and real problem on which everyone can agree, move to discussing solutions. ([View Highlight](https://read.readwise.io/read/01kc1a49qtzedbv40h48pe32yj)) ^965061522 - Making a seed and showing it to a few people isn't enough because most people won't be really critical. They feel it's hurtful. However, ask people to invest even a few hours of their time in making it better, and if they don't say "yes," you know how they really feel. ([View Highlight](https://read.readwise.io/read/01kc1a8nz19bta8m2cnh2mg74q)) ^965061783 - If we, as founders of a group, choose those we work with, we're building in "selection bias." ([View Highlight](https://read.readwise.io/read/01kc1bvgn2ftw58jhccwcw03mt)) ^965065606 The answer is free entry. - Transparency is very important to get rapid criticism of ideas and work in progress. ([View Highlight](https://read.readwise.io/read/01kc1bzy1k8gxjzgqjhfzxgf03)) ^965066001 - When one person does something in a dark corner, that's an experiment. When two or more people do something in a dark corner, that's a conspiracy. ([View Highlight](https://read.readwise.io/read/01kc1bzprk52yzahn1t9f9bpz4)) ^965065987 - 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. ([View Highlight](https://read.readwise.io/read/01kc1c3zpacevs6h1zwc2csc3q)) ^965066090 - A "share-alike" license that enforces two-way remixing. ([View Highlight](https://read.readwise.io/read/01kc1c6brh62p66wa9m86yf6y9)) ^965066306 - Promote the most active contributors into positions of authority, and do this rapidly. You have a short window for promoting new contributors before they disappear to other projects. ([View Highlight](https://read.readwise.io/read/01kc1crknhmbgpje2yfgcrfw4v)) ^965068260 - You have to be a part of your community, and you must follow your own rules. If you find yourself breaking, or wanting to break, your own rules, they are faulty and need fixing. ([View Highlight](https://read.readwise.io/read/01kc1cs09ks6vxm67nz413gex6)) ^965068271 - Stay away from formal membership models, especially those that try to convert people to belonging to the group. Allow anonymous or unidentified participation. Encourage people to create their own competing projects as spaces to experiment and learn. ([View Highlight](https://read.readwise.io/read/01kc1cx1nt941s92h23bktjpcq)) ^965069057 - To measure how tribal a group is, just start a competing project. If the response is negative and emotional, the group is tribal. A sane group will applaud its new competitors. ([View Highlight](https://read.readwise.io/read/01kc1cy69m4cnhs3aka56rgkmk)) ^965069082 - In ZeroMQ, we removed all assigned tasks from the community. For example, we don't accept feature requests. If someone wants a feature, they either send us a patch, or offer someone money to make the change, or they wait. This means people only make changes they really need to make. ([View Highlight](https://read.readwise.io/read/01kc1d37c0kfgxsxkg4k9wwgq9)) ^965069435 - It's a classic anti-pattern to suppress minority ideas and views on the basis that they are "dangerous." This inevitably means suppressing new ideas as well. ([View Highlight](https://read.readwise.io/read/01kc1dc9wsfnw6w0n3jhk6972d)) ^965069939 - This is a difficult lesson that applies to broad society as well: there are no dangerous opinions, only dangerous responses. ([View Highlight](https://read.readwise.io/read/01kc1dbj5b4czewea4xxcnd55b)) ^965069920 - The way communities deal with trolls and vandals is one thing. To deal with fundamental differences in viewpoint is something else. I've said before that conflicting missions can be a problem. The best answer I know is to turn the conflict into competition. ([View Highlight](https://read.readwise.io/read/01kc1ddsh08dx7x9a11dr2rhq5)) ^965069965 - People should be contributing because they need the project to succeed, not to earn toy points. ([View Highlight](https://read.readwise.io/read/01kc1f0cwnxk86e78h6xmeb1qs)) ^965077722 - The freedom to create structure annoys people who feel that it creates chaos and disorder. However, if you use regular structures (see the next section), there's no real cost to participants. What is toxic is speculatively creating structure based on the assumption that people might need it. ([View Highlight](https://read.readwise.io/read/01kc1f6m8p2g05n4hkvanrbqcv)) ^965077957 - Make it absolutely simple for logged-in users to create new projects. If projects are organized per user, you don't need to worry about junk. If they're in a shared space, you may need tools to purge junk and abandoned projects. ([View Highlight](https://read.readwise.io/read/01kc1f982v7wt7q053qvne7vme)) ^965078036 - We seem bad at learning structures deeper than three or four levels. However, we're happy to explore very wide structures with thousands or millions of boxes if those boxes correspond to separate units of work, or projects. Think of a city. ([View Highlight](https://read.readwise.io/read/01kc1fawxx6a52vbmpjj4sdtkf)) ^965078105 - The lack of humor in an organization is a sure sign that everyone there is fundamentally miserable. Worse, it makes the group vulnerable to conflict and fracture. ([View Highlight](https://read.readwise.io/read/01kc1fje8qb0ptt2y190hhzh5r)) ^965078692 - The general rule is do the absolute minimum that probably works. Then invest more only as people start to use your work and complain. ([View Highlight](https://read.readwise.io/read/01kc1fkr8ffcckgjb418mexf17)) ^965078740 - Perfection precludes participation. Releasing buggy, half-finished work is an excellent way to provoke people into contributing. Though it can be hard for big egos to accept, flaws are usually more attractive to contributors than perfection, which attracts users. ([View Highlight](https://read.readwise.io/read/01kc1fmq758fqqy0rbet8vrt71)) ^965078763 - We are essentially economic animals. All of life is economic. We can lie to ourselves really well, yet beneath every act and decision is an economic motive. We invest in projects because we feel they will propel us to success, even if it takes years. We compete with others, trying to find niches where our particular talents can shine. ([View Highlight](https://read.readwise.io/read/01kc2q7gz9g3fwxr4wbb289zt3)) ^965284509 - Individual creativity matters less than process. Smarter people may work faster, and they may also work in the wrong direction. It's the collective vision of reality that keeps us honest and relevant. ([View Highlight](https://read.readwise.io/read/01kc2qfvjgkdtk9m5jm8egq2hh)) ^965286058 - I consider dual GPL/commercial licensing to be a corrupt practice. ([View Highlight](https://read.readwise.io/read/01kc2r8ran8cbabcqhtr0td6d2)) ^965287035 - we are moving towards the Mozilla Public License v2, which has the same effect yet is simpler) ([View Highlight](https://read.readwise.io/read/01kc627te9x12frkjjv20nggfn)) ^965697778 - A lot of languages have multiple bindings (Erlang, Ruby, C#, at least) written by different people over time, or taking varying approaches. We don't regulate these in any way. There are no "official" bindings. You vote by using one or the other, contributing to it, or ignoring it. ([View Highlight](https://read.readwise.io/read/01kc629t4qw4e0tt387wgdshfn)) ^965697836 - iMatix, my firm, plays a specific role in the community. We own the trademarks and enforce them discretely in order to make sure that if you download a package calling itself "ZeroMQ", you can trust what you are getting. ([View Highlight](https://read.readwise.io/read/01kc62d2fvbx39d0wa7wtkghtd)) ^965698290 - if you want to build truly large-scale and long-lasting software, aim to build a free software community ([View Highlight](https://read.readwise.io/read/01kc62hesszma6c9av94gp37rs)) ^965699680 - If there is one thing I've learned and applied successfully in 30 years of making larger and larger software systems, it is this: software is about people. Large structures in themselves are meaningless. It's how they function for human use that matters. And in software, human use starts with the programmers who make the software itself. ([View Highlight](https://read.readwise.io/read/01kc62jy0vgm2ke6vdcz59n14d)) ^965699759 - The two most important psychological elements are that we're really bad at understanding complexity and that we are so good at working together to divide and conquer large problems. We're highly social apes, and kind of smart, but only in the right kind of crowd. ([View Highlight](https://read.readwise.io/read/01kc62nwysz4r1xggy4p894c4e)) ^965699827 - Stupidity: our mental bandwidth is limited, so we're all stupid at some point. The architecture has to be simple to understand. This is the number one rule: simplicity beats functionality, every single time. If you can't understand an architecture on a cold gray Monday morning before coffee, it is too complex. ([View Highlight](https://read.readwise.io/read/01kc62pjkevys4t3h96pb4589k)) ^965699842 #y - We are happiest when we can spend the least effort to get a result or to test an assumption quickly, so the architecture has to make this possible. ([View Highlight](https://read.readwise.io/read/01kc62sgxx5h3k0jbz4n3m419a)) ^965700139 - Jealousy: we're jealous of others, which means we'll overcome our stupidity and laziness to prove others wrong and beat them in competition. The architecture thus has to create space for public competition based on fair rules that anyone can understand. ([View Highlight](https://read.readwise.io/read/01kc62t1fxhaxc9dg4mpyxx4dz)) ^965700152 - The architecture should make silent experimentation easy and cheap, giving people opportunity for success without punishing failure. ([View Highlight](https://read.readwise.io/read/01kc62tp0fxzbtr60amhwmhwqy)) ^965700199 - Greed: we're ultimately economic animals (see selfishness), so the architecture has to give us economic incentive to invest in making it happen. Maybe it's polishing our reputation as experts, maybe it's literally making money from some skill or component. It doesn't matter what it is, but there must be economic incentive. Think of architecture as a market place, not an engineering design. ([View Highlight](https://read.readwise.io/read/01kc62znkea3f9v2dws017049r)) ^965700340 - Ask yourself, "if this project had a big fight, and split three ways, which license would save us?" Or, "if the whole team was bought by a hostile firm that wanted to turn this code into a proprietary product, which license would save us?" ([View Highlight](https://read.readwise.io/read/01kc63620ng6zrerp8m4zhae5w)) ^965700791 - When BSD projects fork, they cannot easily merge again. ([View Highlight](https://read.readwise.io/read/01kc6370wqpmpkqcgxervat76x)) ^965700808 - There was an important language stack called Emacs, originally built in Lisp by Richard Stallman. Another programmer, James Gosling (who later gave us Java), rewrote Emacs in C with the help of many contributors, on the assumption that it would be open. Stallman got that code and used it as the basis for his own C version. Gosling then sold the code to a firm which turned around and blocked anyone distributing a competing product. Stallman found this sale of the common work hugely unethical, and began developing a reusable license that would protect communities from this. ([View Highlight](https://read.readwise.io/read/01kc638zyh6wa66nz7ta738z7v)) ^965700884 #history - the more control you try to assert over the material results, the less people will want to participate ([View Highlight](https://read.readwise.io/read/01kc8m5xby5kyabfjkknb5f1d2)) ^965967410 - You need a goal that's crazy and simple enough to get people out of bed in the morning. ([View Highlight](https://read.readwise.io/read/01kc8m72qk4jpv015612z45p71)) ^965967606 - It must be easy to understand, use, and join. Too many projects have barriers to access: put yourself in the other person's mind and see all the reasons they come to your site, thinking "Um, interesting project, but..." and then leave. ([View Highlight](https://read.readwise.io/read/01kc8m9dx7myat42a1a877ma9w)) ^965968384 - Transparency is essential to get trust, which is essential to get scale. By forcing every single change through a single transparent process, you build real trust in the results. ([View Highlight](https://read.readwise.io/read/01kc8mbm9r4yhha4qcbzaj40gg)) ^965968632 - Another cardinal sin that many open source developers make is to place themselves above others. "I founded this project thus my intellect is superior to that of others". It's not just immodest and rude, and usually inaccurate, it's also poor business. The rules must apply equally to everyone, without distinction. ([View Highlight](https://read.readwise.io/read/01kc8me0ta31dj4dkcv95q3hbb)) ^965968909 - Rules are critical; when done right, they remove friction. ([View Highlight](https://read.readwise.io/read/01kc8mktzsnt5mj68yp0afjd53)) ^965969674 - C4 is an evolution of the GitHub Fork + Pull Model. ([View Highlight](https://read.readwise.io/read/01kc8n5pddneapahr4d4m3fj0s)) ^965970600 - All patches are owned by their authors. There SHALL NOT be any copyright assignment process. ([View Highlight](https://read.readwise.io/read/01kc8ndva0e1gpbdrdht5vxw2e)) ^965970971 - In other words, the maintainers are not karma accountants. Anyone who wants credit has to claim it themselves. ([View Highlight](https://read.readwise.io/read/01kc8nf54kgnhg9wnfpmd9nr9f)) ^965971003 - A patch SHOULD be a minimal and accurate answer to exactly one identified and agreed problem. ([View Highlight](https://read.readwise.io/read/01kc8ngh6w07s16hxe9zfr20g9)) ^965971026 - A patch commit message MUST consist of a single short (less than 50 characters) line stating the problem ("Problem: ...") being solved, followed by a blank line and then the proposed solution ("Solution: ..."). ([View Highlight](https://read.readwise.io/read/01kc8nkqp98m2tqe561gwzey4s)) ^965971096 - Change on the project SHALL be governed by the pattern of accurately identifying problems and applying minimal, accurate solutions to these problems. ([View Highlight](https://read.readwise.io/read/01kc8nmn0ds9x8k0k36ayce7t4)) ^965971328 - Users SHALL NOT log feature requests, ideas, suggestions, or any solutions to problems that are not explicitly documented and provable. ([View Highlight](https://read.readwise.io/read/01kc8nnqg9fyj97nsk95bykkke)) ^965971346 - Maintainers SHALL merge correct patches rapidly. ([View Highlight](https://read.readwise.io/read/01kc8nrnrx50gk6zvcy4tmqtfd)) ^965971493 - Maintainers MAY merge incorrect patches from other Contributors with the goals of (a) ending fruitless discussions, (b) capturing toxic patches in the historical record, (c) engaging with the Contributor on improving their patch quality. ([View Highlight](https://read.readwise.io/read/01kc8paagcb7mj0bv3c58tsrz6)) ^965972349 - OM: second contributor joins in to help first fix their patch. We get a short, happy patch party. New contributor now has a coach and friend in the project. ([View Highlight](https://read.readwise.io/read/01kc8pcbm8bsgdhn4ntgpejeet)) ^965972450 - In the majority case (patches that need further work), Optimistic Merging creates the conditions for mentoring and coaching. And indeed this is what we see in ZeroMQ projects, and is one of the reasons they are such fun to work on. ([View Highlight](https://read.readwise.io/read/01kc8pdref0za1an2xecaeg68v)) ^965972521 - The user who created an issue SHOULD close the issue after checking the patch is successful. ([View Highlight](https://read.readwise.io/read/01kc8pdzqnrs6jcr2wexbxsatr)) ^965972530 - Any Contributor who has value judgments on a patch SHOULD express these via their own patches. ([View Highlight](https://read.readwise.io/read/01kc8peha91p2n7hzbd64zyyhq)) ^965972543 - We had road maps, and we deleted them. Instead of a few experts trying to lay out the next steps, we were allowing this to happen organically. ([View Highlight](https://read.readwise.io/read/01kc8x7212pgegmd5ndfk957pp)) ^965984841 - As we rolled out releases, we hit the problem that it's very easy to promise stuff, and rather harder to make it as planned. ([View Highlight](https://read.readwise.io/read/01kc8x8fkkm9ye87dyne1t5gmv)) ^965984925 - The second problem was that by defining the road map, we in effect claimed territory, making it harder for others to participate. People do prefer to contribute to changes they believe were their idea. Writing down a list of things to do turns contribution into a chore rather than an opportunity. ([View Highlight](https://read.readwise.io/read/01kc8x995g5ccv4ea93rbkj935)) ^965984976 - Individual creativity matters less than process. Smarter people may work faster, but they may also work in the wrong direction. It's the collective vision of reality that keeps us honest and relevant. ([View Highlight](https://read.readwise.io/read/01kc8xbvyrg38y5axdy6e753wj)) ^965985070 - We don't need road maps if we have a good process. Functionality will emerge and evolve over time as solutions compete for market share. ([View Highlight](https://read.readwise.io/read/01kc8xcdxznpb7vf9szwec3vmn)) ^965985088 - The size and diversity of the community is a key factor. Larger, more diverse communities collect more relevant problems, and solve them more accurately, and do this faster, than a small expert group. ([View Highlight](https://read.readwise.io/read/01kc8xdcem8wgy9mdhh0zb3r0p)) ^965985124 - Ideas are cheap. No exceptions. ([View Highlight](https://read.readwise.io/read/01kc8xmtb6dyhm6s8svjeyzgxf)) ^965985356 - The starting point for a good design process is to collect real problems that confront real people. The second step is to evaluate these problems with the basic question, "How much is it worth to solve this problem?" Having done that, we can collect that set of problems that are worth solving. ([View Highlight](https://read.readwise.io/read/01kc8xn98k10jcz3xabehz43jf)) ^965985370 - Good solutions to real problems will succeed as products. ([View Highlight](https://read.readwise.io/read/01kc8xp4ppbzktdcefyf0t1yze)) ^965985399 - Making stuff that you don't immediately have a need for is pointless. ([View Highlight](https://read.readwise.io/read/01kc8xtv9vxmn29pn72mx2pk1a)) ^965985522 - Ironically, solving the simpler problems often has more value to more people than solving the really hard ones. ([View Highlight](https://read.readwise.io/read/01kc8xvb7tbbynnmf4tjqskjed)) ^965985531 - It is crucial to have a "stop mechanism", a way to set short, hard deadlines that force people to make smaller, simpler answers to just the most crucial problems. ([View Highlight](https://read.readwise.io/read/01kc8xw5g2evk94zdtkdtmj5ef)) ^965985547 - Finally, we come to the rare but precious Simplicity Oriented Design, or SOD. This process starts with a realization: we do not know what we have to make until after we start making it. ([View Highlight](https://read.readwise.io/read/01kc8xwvg7wz0e6qk5936m3421)) ^965985564 - We take the simplest, most dramatic problem and we solve this with a minimal plausible solution, or "patch". Each patch solves exactly a genuine and agreed-upon problem in a brutally minimal fashion. ([View Highlight](https://read.readwise.io/read/01kc8xxtbmpw3m3nr6nvbws8j3)) ^965985617 - We apply one measure of quality to patches, namely "Can this be done any simpler while still solving the stated problem?" ([View Highlight](https://read.readwise.io/read/01kc8xy47cmrp1cg9t8n7h9x17)) ^965985625 - We build our projects into a supply chain where each project can provide problems to its "suppliers" and receive patches in return. ([View Highlight](https://read.readwise.io/read/01kc8xz6qvg37hnd7d83jx1cyx)) ^965985642 - At every moment from the very first patch, our product is shippable. This is essential, because a large proportion of patches will be wrong (10-30%) and only by giving the product to users can we know which patches have become problems that need solving. ([View Highlight](https://read.readwise.io/read/01kc8y0x8ekhgmdjbz3092eqek)) ^965985674 - if someone in your organization is irreplaceable, get rid of him or her. ([View Highlight](https://read.readwise.io/read/01kc8y59b7rb8vmxhbahmkzq3v)) ^965985823 - Never design anything that's not a precise minimal answer to a problem we can identify and have to solve. ([View Highlight](https://read.readwise.io/read/01kc8y7yw0xcmnswskv36scngq)) ^965986116 - Allowing others to learn by failure gives the good reason to stay, and the bad excuse to leave. The Hangman is endlessly patient, because there is no shortcut to the learning process. ([View Highlight](https://read.readwise.io/read/01kc9gfc5wpvbscvzdr7726g0y)) ^966036007 - For a software to be a "living system", it must be used by the organization that builds it, and it then lives or dies along with that organization. ([View Highlight](https://read.readwise.io/read/01kc9gmqgn346hm3txwexpdzks)) ^966036266 - Look at a software project and ask, "who is the designer?" If there is a clear designer, individual or organization (and there almost always is), that is a Planned System. A Living System has no designer, no road-maps, no clear future plans except "survive and grow." ([View Highlight](https://read.readwise.io/read/01kc9gvqmewmpkg584pv3gakxd)) ^966036625 - A Living System looks more like Adam Smith's free market than Stalin's Five Year Plan. ([View Highlight](https://read.readwise.io/read/01kc9gw8816ez2883kyyex783y)) ^966036641