Community Building & Social Architecture

Other material on Community Building & Social Architecture:

user_add.png

Why Optimistic Merging Works Better
I spoke at DomCode in November 2015 (excellent conference, small and beautiful city!) explaining my top rules for building open source communities. One person asked me later to explain why I recommend to merge quickly, without waiting for Continuous Integration testing to finish, and without review of the code. I'm going to call this strategy Optimistic Merging or OM. Here's the reasoning behind OM.

date.png16 Nov 2015 15:14 | comments.png 10 Comments | tags.png community
clash.png

Ten Myths About Harassment
Today I watched a revealing video of Yale students with a professor. The mob insult and harangue someone with decades of experience defending free speech. It goes on far too long and leaves us disturbed. These young people act like a pampered, idiot mob. And yet you cannot deny their deep anger. Who is the harasser, and who the harassed, in this video?

date.png10 Nov 2015 19:56 | comments.png 2 Comments | tags.png community psychopaths
action.png

Amdahl to Zipf: Ten Laws of the Physics of People
When we make software, laws of physics apply. I call this the "physics of people." When we ignore these laws, our work collapses like a badly designed bridge. Maybe you didn't realize Einstein's Equivalency Principle applied to you? Then read on, and be enlightened…

date.png08 Oct 2015 09:34 | comments.png 4 Comments | tags.png community
speedometer_black1.png

Ten Rules for Open Source Success
Everyone wants it, lots of people try it, yet doing it is mostly painful and irritating. I'm speaking about free software aka open source. Today I'm going to summarize 30 years of coding experience in ten management-proof bullet points.

date.png22 Sep 2015 09:40 | comments.png 2 Comments | tags.png community
chart2.png

C4.1 - an Exothermic Process
In February 2012 the ZeroMQ community said "adieu" to its long time maintainers, and set sail in a new direction. Using a new process called C4.1 as its compass, we headed off into unknown territory. Looking back three and a half years later, what is the result? Did ZeroMQ lose its way, as many predicted and feared? Or did the new process work as planned?

date.png16 Sep 2015 20:49 | comments.png 2 Comments | tags.png community zeromq
check_dotted.png

The End of Software Versions
Software version numbers are the crack cocaine of change management. They are an easy and attractive path to serious long term stress and pain. The worst ever distress in the ZeroMQ community came from allowing library version numbers to define compatibility. The reasons are real, yet subtle and often counter-intuitive. In this article I'll explain in detail, and propose a replacement for software versioning.

date.png06 Feb 2015 14:20 | comments.png 0 Comments | tags.png community zeromq
nodes2.png

The Power of Living Systems
A "Living System" is one that grows into its environment, by self-organizing around opportunities. Living systems can last for a long time, adapt well to change, and thus be highly successful. By contrast, "Planned Systems" tend to be fragile, poor at coping with change, and thus short-lived. In this article I'll explain Living Systems, of software and people, and how to grow them.

date.png27 Jan 2014 08:22 | comments.png 0 Comments | tags.png community
briefcase1.png

How To Capture an Open Source Project
Ars Technica has an interesting article on how Google is closing off Android piece by piece. It is a classic game of "capture the flag", played against an open source community. I'm going to explain how this capture works, and how to prevent it.

date.png21 Oct 2013 12:08 | comments.png 0 Comments | tags.png community
equalizer2.png

The Castle and the City
One of the topics for my upcoming book "Culture and Empire" is how to build online communities. I'm going to argue that there are two general layouts for a large organization — the Castle and the City — and compare these. Is your project a Castle, or a City?

date.png29 Jul 2013 16:59 | comments.png 0 Comments | tags.png community writing
clash.png

The Gender Gap in Coding
My daughter, nine, comes with me to tech conferences like FOSDEM, in Brussels. She's been using a Linux PC since she was two, self-taught and self-motivating. I'd like to teach her to code, and perhaps make a profession in the software industry. But the chances she'll succeed at that are getting lower each year. I think there's a reason for the so-called "gender gap" but it's not any of the usual explanations.

date.png29 Apr 2013 21:33 | comments.png 2 Comments | tags.png community writing
check1.png

10 Tips for an Awesome Open Source Project
In this article, ten top tips for making your open source project awesome! We've collected these tips by paying scientists to study the most awesome open source projects in the world. Whether you're starting a new open source project, or open sourcing your company's kind of old codebase, these tips will help you. Enjoy and retweet!

date.png29 Apr 2013 13:53 | comments.png 0 Comments | tags.png community writing
quote2.png

How to Make Money from Open Source
There are, it has been said, two ways to make really large-scale software. Option One is to throw massive amounts of money and problems at empires of smart people, and hope that what emerges is not yet another career killer. If you're very lucky, and are building on lots of experience, and have kept your teams solid, and are not aiming for technical brilliance, and are furthermore incredibly lucky, it works.

date.png18 Sep 2012 11:02 | comments.png 0 Comments | tags.png community process
download_screen.png

The End of Stable Releases?
The C4 process we adopted some time back for ZeroMQ (except our dependency on Jira), CZMQ, and some other projects, looks like it's working as planned. But the drama of science lies in the extremes. If we really can reduce change latency to almost zero using C4, how does this affect how we deliver stable releases?

date.png25 May 2012 17:01 | comments.png 0 Comments | tags.png community process
chart2.png

The Myth of Intelligent Design
The dominant theory of design is that you take smart, creative people and money, and produce amazing products. The smarter the people, the better the results. I'm going to claim that theory is bogus and based on a quasi-religious model of the "inventor" and "invention" as a function of individual minds. As an alternative I'll present the Theory of Heuristic Innovation, which states roughly that we do not invent solutions, we discover them, and that discovery process can be highly automated.

date.png10 May 2012 21:10 | comments.png 0 Comments | tags.png community process
forbidden.png

Git Branches Considered Harmful
One of git's great features is how easy it makes branches. Almost all git projects use branches, and the selection of the "best" branching strategy is like a rite of passage for an open source project. Vincent Driessen's git-flow is maybe the best known. It has 'base' branches (master, develop), 'feature' branches, 'release' branches, 'hotfix' branches, and 'support' branches. Many teams have adopted git-flow, which even has git extensions to support it. However, in this article I'll argue that public git branches are harmful, based on experience and evidence, and propose a branch-free approach, based on forks.

date.png09 May 2012 21:49 | comments.png 9 Comments | tags.png community git
chart3.png

Good, Cheap, and Fast - PC3
The Pedantic Code Construction Contract (PC3) is an evolution of the GitHub Fork + Pull Model, and the ZeroMQ C4 process, aimed at providing an optimal collaboration model for commercial software projects. PC3 helps an organization build consistently good software, cheaply, and rapidly.

date.png29 Mar 2012 16:12 | comments.png 0 Comments | tags.png community process
bookmarks.png

The Lazy Perfectionist and other Patterns
In this article I'm presenting a series of patterns for success in software engineering. These patterns aim to capture the essence of what divides glorious success from tragic failure. They were described as "religious maniacal dogma" by a manager, and "anything else would be fucking insane" by a colleague, in a single day. For me, they are science, the results of decades of trial by error. Treat the Lazy Perfectionist and others as tools to use, sharpen, and throw away if something better comes along.

date.png01 Mar 2012 20:00 | comments.png 2 Comments | tags.png community process
heart.png

Social Engineering 101
Social architecture is the discipline of designing and building large-scale, successful on-line communities. An underlying toolkit is the more focused skill of social engineering, or making friends and influencing people. It's often confused with social hacking but is quite different. In this article I'll explain the basics. As a case study I'll tell the story of how I talked myself into seat 2A in first class on United UA 973, Brussels to Chicago.

date.png08 Feb 2012 19:23 | comments.png 1 Comments | tags.png community
clash.png

Diversity is Joy
If you're into community building, you will inevitably bump against individuals who cost you sleepless nights, who draw you into endless email threads debating the most inane details, and who generally turn what should be a pleasant win-win experience into a war of words. In this short article I'll explain how to deal with such people.

date.png04 Feb 2012 19:50 | comments.png 0 Comments | tags.png community
tweak.png

How to Design Perfect (Software) Products
My tweet "Still amazed by the power of engineers to over-design. Complexity is easy, folks, it's simplicity that is hard" got over 50 retweets. Clearly I touched a nerve in a world swimming in hopeless complexity. But talk is easy. How do we design for simplicity? Well, I've got a process, which I will explain. I call this process "Simplicity Oriented Design", or SOD.

date.png29 Jan 2012 12:33 | comments.png 0 Comments | tags.png community
bug.png

The Economics of Evil
In 2008 I'd been president of the FFII for two years and we worked hard to get people involved in the fight against software patents. We developed the rule of thumb that positive campaigns don't work. Every campaign needs a bad guy. So as I moved back to building open source communities, I wondered how this rule could translate to different kinds of community.

date.png26 Jan 2012 01:15 | comments.png 0 Comments | tags.png community
user_add.png

Testing Considered Evil
Here's a provocation: the more you test software, the worse it will be. To understand why, I need to explain how we (as a profession or industry) actually make good software. Very few people understand this, and we use techniques like unit tests for support, not illumination.

date.png04 Oct 2011 12:53 | comments.png 0 Comments | tags.png community
stop1.png

How to Recognise and Prevent Burnout
Any organisation or community that relies on pro-bono efforts from its members runs the risk of burnout. In this article I'll explain what causes burnout, how to recognise it, how to prevent it, and (if it happens) how to treat it. Disclaimer: I'm not a psychiatrist and this article is based on my own experiences of working in pro-bono contexts for the last 20 years, including free software projects, and NGOs such as the FFII.

date.png23 Jun 2011 13:53 | comments.png 0 Comments | tags.png community
chart3.png

How to Grow a Community
There are a few ways people define open source or free software. One is by the license: "yes, we can see the code". Two, is by process: "yes, anyone can contribute". Three is by community: "yes, it's built by all of us". For me, only the last measure counts, and steps one and two are milestones. But they're not sufficient, as many failed projects show. I'll present fifteen measures that I've extracted from years of trying (and sometimes managing) to build self-steering, sustainable communities. You tell me if I'm on the right track here or not.

date.png07 Jun 2011 14:50 | comments.png 0 Comments | tags.png community
team1.png

Psychological Elements of Software Architecture
Dirkjan Ochtman pointed me to Wikipedia's definition of Software Architecture as "the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both". It's a good example of how miserably little we understand about what actually makes a successful large scale software architecture.

date.png06 Jun 2011 09:20 | comments.png 0 Comments | tags.png community
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License