Unprotocols

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.

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.

Good, Cheap, and Fast - PC3
The Pedantic Code Construction Contract (PC3) is an evolution of the github.com 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.

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.

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.

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.

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.

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.

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.

A Tale of Two Bridges
Two old engineers were talking of their lives and boasting of their greatest projects. One of the engineers explained how he had designed the largest bridge ever made.

Credit-based Flow Control
Using network buffers - such as 0MQ's queues - has a disadvantage when you are sending data to many readers. Your writer will block when the buffer is full. To avoid this, you can use non-blocking writes, and poll for sockets that are 'ready for writing'. But here's an alternative that dispenses with high-water marks and blocking writes. It's called "credit-based flow control".

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.

MOPED - a Message-Oriented Pattern for Elastic Design
People learning to build distributed systems with 0MQ for the first time (there's a protocol joke in there somewhere) can make some awful mistakes. One cannot just convert design approaches like "let's make a structure of classes" into "let's make a structure of tasks". So, here's a simple design pattern, that I call MOPED, for building distributed systems. Surprisingly, MOPED works, and is fun.

NOM-1 grammar and notes
Time to get formal. Even the simplest contracts have to be robust against our charming but ineradicable stupidity. Perhaps the simplest formal language for an unprotocol is ABNF. So here is a first draft grammar for NOM-1, with notes. This page will morph into a real unprotocol draft spec.

First steps to NOM-1
NOM-1 is a lightweight messaging unprotocol for #zeromq over UDP. The name stands for "NOM-oriented messaging". There's a good reason for the cuteness. If I gave it a confidence-inspiring name like "Message-oriented Datagram Protocol", people might use it without further thought. The silly name will make life and public acceptance hard for NOM-1. So it's going to have work really hard to succeed.

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.

Cheap and Nasty, two essential patterns
Unprotocol enlightenment comes one step at a time. While it can be tempting to try to use generic solutions, it's often wiser to divide problems into classes, each with an optimal solution. Let's look at Cheap and Nasty, two essential patterns for unprotocol design.

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.

Clouds and Unprotocols
The future seems clear. Mobile applications, clouds, and unprotocols. My previous gig was CEO of Wikidot, which runs this site. It's a cloud. Cheap, scalable, instantly available to anyone who needs it. My next gig will be portable applications. Always available, smart, geolocated, social. Put the two together and you have something magic, as Google knows.

Smallest Stack Ever
@dln_eintr (Daniel Lundin) broke two or three records with this one: zmq_push() { m=$(cat) && echo -e $(printf '\\x01\\x00\\x%02x\\x00%s' $((1 + ${#m})) "$m") | nc -q1 $@; }

Majordomo and Titanic in PHP
The Majordomo Protocol and Titanic Service Procotol are two neat little unprotocols built on top of ØMQ. Ian Barber (@ianbarber) has just made PHP implementations of these.

Using a RESTful Transport Layer
Couple of us are developing a new mobile concept, which I'll write about later somewhere else. The little thing talks to a web service, and for this we're using RestTL, an unprotocol that "specifies standard rules for representing resources, and standard mechanisms for working with them in a RESTful fashion over a plain HTTP client-server network."

Finally, the ØMQ wire level protocol!
ZMTP/1.0 defines the wire level protocol used by ØMQ (versions 2.x) over TCP. It has a framing layer, a connection layer, and a content layer. It's a neat little unprotocol that is free to remix, lightweight, and easy to understand.

Keywords for Unprotocols
Up to now, software protocols have been designed with levels of formality that tend to exclude facile participation from the fat belly of developers. tl;dr: protocols in suits bore the pants off most of us. We propose the concept of the "unprotocol", which is a lightweight spec that's easy to read, fast to implement, and obvious to get right.

Elegant Little Pieces
Unprotocols are elegant little pieces that we remix to create order and sanity in the swirling chaos that is the software industry. There are, IMO, three essential properties of an unprotocol. One, it's immune from capture. Two, it's lightweight. Three, it uses natural semantics. Said @leastfixedpoint: It's a mystery to me why AMQP isn't yet specified in little elegant pieces like this: http://rfc.zeromq.org/spec:13.