Ricky Road: The open-source gaming community

Open source projects have a major problem that is becoming alarming. No one seems to agree on anything.

When I was 19 I had been a professional illustrator for over two years. I had started out doing caricatures at the local amusement park and moved on to doing private work. During this time I was approached by two young ladies who had a business proposition for me. They had a small "art" company that was focusing on photography, pottery and illustration. The name of the company was "Wonderfully Made" (I, obviously, didn't have much say in the name). One of the girls was the CEO and the other was the creative influence. And adding me, I was the so-called "talent". So we talked about what they had in mind and how they could use me and their basic business model. They wanted me to design and paint murals for residential and business clients. I was very interested and agreed to work with them. It was a great idea, with one small issue, I was the only one who knew how to draw or how to paint. In fact if you want to drill down closer to the heart of the problem it would be: I was the only one who knew how to draw and paint and I knew it. And so did they.

Ignoring this issue, we began to work together quite happily and we started meeting with clients. One of our first was a client who wanted a Little Bear mural in one child's room and an "Animal Jungle Landscape" in the other child's room. They were a great couple and really a joy to work with. However during the initial planning phases of the murals we began to have some disagreements among the company employees. I recall that a few drawings were rejected because of the number of monkeys on the page was too high or too low (the perfect balance of monkeys to parrots is crucial to any jungle scene. Any real jungle scene artist will tell you that). And I was politely reminded of my incompetence by my superior. So after a few redraws we had a final draft of the "production" illustration.

So the big day came and it was finally time to put the drawing on the wall. We had discussed our technique and everyone was ready to go. The girls and I were going to paint it together. Okie Dokie. So on that morning I had an issue that caused me to be an hour or two late to the start (I honestly can't recall what it was), and when I got to the house the girls had already jumped in. And this is where it gets ugly. I still remember the split second I walked into that room. It was like my very child had been ripped from my hands. Oh, the horror. The freakish creation that my work had become still haunts me to this day. I still apologize to the world for that beast being unleashed upon man. The only thing that could come out of my mouth at that time was "WHAT THE HELL ARE YOU THINKING!!? ALL YOU HAD TO DO WAS TRACE THE DAMN DRAWING FROM THE PROJECTOR TO THE WALL!! YOU CALL THAT A ZEBRA HOOF??!? OMG!". I don't want to exaggerate but I do remember kids crying, dogs yelping, and shortly thereafter being in the car. No radio, no one talking, just silence. It felt like after 9/11. Everything had changed.

We never worked together again. I don't think "Wonderfully Made Inc" had the gusto to keep going without anything to make.

Its funny that this situation happened to me so young and so early in my professional life because it sets a valuable precedence. You aren't always as smart as you think you are and sometimes your vision, even when its quite literally drawn precisely on paper, isn't always understood by the team you work with. And for those of you just starting out in your careers, in your life, that situation is going to happen and it doesn't get easier. Hopefully you will find a group that values the respect they have for each other more than recognition they may get from other people.

But that isn't the point of this message. How you deal with it personally is your business. What I want to talk about is how the industry, our industry, deals with it.

Don't code in the dark

Take a minute to read this Coding Horror: Don't Go Dark

If someone on your project codes alone for weeks and springs a wide swath of changes to your project what do you do? We work as a team, I have ideas, you have ideas. We have that happening in many situations. But can the group come to a consensus? What ideas are worth pursuing and what is a waste of time? But what happens when a contributor has an idea and it is either not agreed upon by the others as worth pursuing or the contributor feels he/she won't even bring the idea to the groups attention because of the fear of rejection? And what if they code it anyway?

Lets get beyond coding in the dark to the crux of coding in the dark. What if we are making decisions about features in the dark? Coding itself is a microcosm of deciding on features. After all even the smallest loop is logic that provides a feature to a feature to a feature that will eventually enable a tangible "Feature". And all features are enabled by many many smaller individual features created by the developer, the language, the platform, and the processor. Every piece of code that you write is a tiny opinion of yours implemented and wrapped in syntax. You communicate your opinions into instruction that is carried out by the system. So what happens when your little opinions enable other bigger opinions and your creation begins to quack like you quack and walk like you walk and has your face and your smile? Only your momma thinks your good looking, and no one knows what your evil little mind is up to when it is all alone. Then suddenly you spring your code back to the group and say "your welcome." And then they all look at you and say its piece of shit...
And in effect you feel as though YOU have been called a piece of shit.

Welcome to what happens every day in open-source. So what do we do? Unfortunately we break up the band, or at least we lose a drummer. Or maybe you, the drummer, are replaced with another drummer. They split and call it "creative differences". And it happens because not everyone draws a zebra hoof the same way and not everyone likes JSON or XML.

An open source project is a very different animal. It's a motley collection of widely distributed, loosely coupled volunteers. There's no project manager breathing down your neck, urging you to break your work into short, shareable increments. The risk of going dark is severe. The burden of proof falls on the individual developers, not only to make their work on the project visible in modest increments, but also to get over their code insecurity and share their in-progress code with other people working on the project. How do you expect your fellow coders to take you seriously if you aren't regularly showing them code? It's the only form of currency that matters on an open source project.

Jeff Attwood is talking about the difference between a development team in a typical corporate environment and open-source developers. Transparently showing your code to other developers is a burden that falls on both the individual developer and the group to enforce in the open-source industry. In a proprietary group, contributors are held closely accountable with the aid and enforcement of a management team, and a rigid peer review process. They simply have a shorter leash and aren't free to roam the wildly evil prairies of their own imagination unsupervised.

300+ different variations of Linux and counting

I didn't stop drawing after I left "Wondefully Made Inc". In fact I still draw today. I just didn't draw with them anymore. We still went on to pursue our work, we just couldn't work together due to our own personal deficiencies of character and inability to agree. And since we weren't forced to work together, we didn't. And in Open-source no one is forced to write for a project. So, if someone tells some one to "%$#$ off, your code blows and your ideas blow harder" they simply leave. What compelling reason would they have to stay?

There is an interesting term in the development industry called the "Bozo bit". Once someone flips the bozo bit on you, you are officially a bozo to that person.
Rule #4: Don't flip the bozo bit. A classic rule from a classic programming book Dynamics of Software Development.

Believe it or not, most people don't want to think. They think they want to think, but they don't. It's easier not to and to instead flip the bozo bit-that's what we call it at Microsoft: "That dude's a bozo!" Then nobody pays attention to anything the putative bozo says or does forevermore. And as far as making a contribution is concerned, he's just dead weight, a bozo.

A bozo, of course, is not to be trusted with anything. The best you can hope for is that the bozo will be paid to do nothing of consequence and therefore won't screw up the works. This is, to say the least, too modest an ambition for anybody who occupies one of these valuable slots on your team.

I would be willing to bet everyone reading those paragraphs immediately has a name pop in to their minds. And sometimes that name might be your own.

So what happens when the bozo isn't paid and works on a open-source team. He simply doesn't stay on the project. And unfortunately all too often, bozo bit flipping happens on people who were never bozo's in the first place. Too much a bozo bit flip happens because of the differences in opinion about JSON vs XML and CVS vs SVN. And the so called bozo, who was never really a bozo, goes on to write virtually the same thing with just a different project name and his features and ideas. And after this happens enough times, major projects start splintering. Just take a look at all the different versions of Linux that have been created over the years.

So now what? It's not a matter of just gritting your teeth and treating people differently when you feel like walking away. Don't pretend to respect anyone, that seed will always find the light of day if it isnt sincere.

Right now we know that sometime in the future your project is going to have some contention stemming from differing opinions. There is nothing you can do about that. It's a constant. So why wouldn't you prepare now? This was the heart of the idea behind democracy itself. I don't mean democracy as in just voting I mean what democracy enables in a society. It creates a way to operate in complete freedom and create a system for the people, of the people and by the people. It creates a system that will adequately compensate for the pitfalls that can doom a government or a tiny open-source software project. It creates a system that allows everyone to work freely and have everyone's opinion and ideas accounted for equally. They knew in advance that people would argue and that people would outright hate each other at times, but above all they preserved their project.