Five Laws of Open Source

In order to work effectively, open source as a paradigm has a set of rules. There are a few examples of rules out there, but I think I can help, because I’ve got no problem flouting the rules when I feel like it. (Guess which ones I’m flouting!)

  1. Be thou not a jerk.
  2. Conserve not thy knowledge, for knowledge, unlike material goods, loses value in scarcity and gains value in propagation.
  3. Respect thine ego as it deserves, which is to say: not at all, for upon the shoulders of humble giants dost thou stand, and if afraid to look stupid had they been, their shoulders available for thy standing would not have been.
  4. Don’t talk like Yoda. It violates the first law, geez.
  5. Expect participation to be its own reward.

Be Thou Not A Jerk

This should be fairly obvious. While open source definitely has its share of prima donnas, try hard not to join their ranks; most of the prima donnas out there really don’t have the social capital to justify their behavior.

You really shouldn’t attack anyone. Avoid all ad hominem attacks; if an idea isn’t as strong as it should be, well, say so – and say why – but even a bad idea doesn’t mean that the idea’s author is stupid.

Maybe the idea is perfect for what the author is trying to do, after all, and they’re speaking from their perspective; even if the idea is a terrible one, it’s worth using gentleness.

If forceful behavior is justified (i.e., someone has a terrible idea, it’s been rejected through reasonable explanation, and the author gets abusive or insistent beyond reason), then… honestly? Excommunication in context is the best approach in most cases. Just mute the poor fellow in the context of the project; document the idea and why it isn’t a good approach for the project at large (see the next rule!), and move on.

Abuse is dangerous; it poisons the community, and makes you look bad, even if it’s justified in your mind.

Obviously, trolling is a terrible idea for everyone. I’d say the same for sarcasm, but I’m pretty sarcastic myself and my ego wouldn’t survive that kind of self-examination.

Conserve Not Thy Knowledge

In the Real World, scarcity drives up value. If you’re the only person in the world with a particularly nice guitar, well, that guitar is going to (potentially) be worth a lot, because of scarcity; if anyone else wants it, well, they’ll have to compete for that unique object.

Likewise, if a resource is limited – like, say, oil – people with need of that oil are subject to market scarcity; the less oil that is made available to the consumer, the higher the price that the consumer must be willing to pay.

Knowledge is not like that. If you’re the only person who knows something, that knowledge isn’t worth much. But if you tell everyone, all of a sudden that knowledge is incredibly valuable.

There are obvious retorts to this; if you’re good at something, and people need someone who’s good at whatever it is, they’ll (hopefully) be willing to pay more to acquire the services of skilled personnel. (Look at basketball teams: everyone knows how to shoot a basketball, but the people who are actually really good at it get paid bazillions.)

But I’d say that in open source, that doesn’t work; there are exceptions, of course, but the general situation is such that knowledge is worth more when it’s shared.

If you figure something out, say what it is, from beginning to end. Describe what it is that you’ve figured out, and describe how it works, why it works, where you’d use it. Go overboard. Drown people in your knowledge. Make it so that if you were to be hit by a bus tomorrow (God forbid! … or The Cold Unfeeling Universe forbid! … or whatever) that what you’ve learned could be replicated 100% by someone who could read the documented knowledge you’ve left behind.

It doesn’t matter, really, even where you left it – as long as it’s publicly available. If Google can find it, it’s good. I’d suggest avoiding social networks, though, because social networks artificially inflate the propagation to a specific subset of people (the social network itself), and the idea is to be egalitarian.

Respect Thine Ego As It Deserves

Having an ego is healthy. However, remember that your ego – your pride in self – is best served in open source by remembering that you stand on the shoulders of those who came before you.

You may have reached a pinnacle of knowledge, but in open source, that usually means that you, yourself, took that last step to reach the top of the mountain – while everyone else carried you to the previous position. Everyone else built the ladder that you have climbed.

That’s not to devalue that last step – someone has to do it! But bragging about being the one who made the leap is in very poor taste.

In open source, we all build together.

Someone else (probably) built the operating system you use. Someone else (probably) designed the language you used to you write your project. Someone else (probably) developed methodologies for development that you used. Someone else (probably) defined the environment in which your project will operate.

Very few of us are capable of actually working alone in all of this; we all leverage the information that others have made available.

So.. yeah, be proud of who you are and what you’ve contributed, but remember that it’s another diamond in an wasteland full of such jewels.

Humility is your friend… and it saves you a lot of embarrassment in the rare event that you’ve screwed up. Let pride drive you to do things well, but don’t let pride dictate how you interact with others. Let others sing your praises; about yourself, be silent. (Enough moralizing from the moron at the keyboard.)

Don’t Talk Like Yoda

Look, I get it; Star Wars is fantastic in a lot of ways that matter. (Great special effects, especially for the time; a grand storyline; great ideas.)

However, it’s awful in a lot of other ways: the dialogue, especially when George Lucas wrote it, was terrible, and a lot of the problems had really simple solutions (often as simple as “eliminate the so-called ‘good guys’ and the ‘bad guys’ wouldn’t be all that bad. They’re mostly evil because the filmmakers wanted to have good villains. Except Jar-Jar. He’s raw malice wrapped in a can.”)

And then there’s Yoda.

I won’t bore you with criticism of Yoda beyond his speech patterns, which are… unique, and surprisingly hard to replicate well.

The simplest way to imitate Yoda, though, is to invert the structure of a sentence. Speak with passive voice, you should do! Learn this way of speaking, you should not!

… okay, this rule was me picking on myself, for writing the first three rules in Yoda-speak. Don’t follow my example; don’t use Yoda-speak. Really. (Or: “Speak like Yoda you should not, ha ha ha! Why you are making faces like that, I do not know.”)

Expect participation to be its own reward

This is the hardest one, I think (unless it’s “Don’t talk like Yoda”.)

But this is the one that makes it all work.

When you participate in open source – when you ask a question, when you tell a newbie how to do something simple, even when the docs show it somewhere… you contribute value. You build. You make the world a better place.

If you want more than that… well, you might get it, but you probably won’t. The truth is, that knowledge that you’ve helped improve the world around you is the most likely reward you will see.

Being honest, if you participate a lot, you will probably gain a sort of social capital; people respect that participation, and the value you contribute eventually will come back to you.

I’m proof of that, I think; when someone asks a question, I’ll often try to answer and guide. Sometimes I’m flat-out wrong, and that’s fine; someone more knowledgeable will correct me (sometimes even gently) and then everyone learns… but the key is that I can usually ask my own questions and people will try hard to answer me, because they know that I will share that knowledge to others, and because they (for better or for worse) respect my intentions to participate.

That’s social capital. I wouldn’t know (or want to know) how much social capital I have, nor would I know how to quantify it, but what social capital I do have, I think I can directly attribute to my expectations of reward.

If someone asks a question that I can answer, I don’t expect anything from them apart from their growing knowledge. And I shouldn’t.

Again, sometimes it works differently; sometimes you help someone and they return the favor to everyone’s benefit. Sometimes they pay it back; often they pay it forward (a more desirable result).

But if you act in open source in such a way that you want what you offer paid back… that’s a violation of open source principles.

Don’t do it. Pay everything forward, and expect that from others. Everyone wins that way.

Your Infrastructure Uses Programming Principles Too

It’s important to remember that your development and deployment infrastructure uses programs, written by programmers. Because of that, sometimes things will break, and while that’s not fun, it’s still just programming – report bugs, try to figure out fixes and workarounds, discuss, and contribute, just like you would with any other programming situation.

Of course, if you encounter bugs and refuse to report them or try to fix them or even document them, I’d say you’re working against your own best interests. You’re far better off participating, even if it’s as shallow a participation as “Hey, I found a bug when I …” because that at least helps track the number of people affected by a problem.

And in the end, it’s a programming problem – it’s likely to get fixed, because we, as programmers, like things to work. It’s pointless to just throw shade at systems, regardless of what they are or even if they deserve it.

Problems are just problems. There are solutions.

In May of 2016, a programmer removed left-pad from the the Javascript ecosystem. In the process, he broke thousands of dependent projects that used left-pad.

This was a big problem. (Thank you, Captain Obvious!)

But why is it such a problem, in the grand sense of things? I’d say it was a serious failure, to be sure. But triaging the issue realistically, there were workarounds in very little time (namely, replacements for left-pad) – and it also highlighted the importance of redundancy and licensing in the Javascript ecosystem. Two problems, one fairly limited (the dependency on left-pad) and one broader in scope but normally something people were able to ignore (the availability).

Both ended up being addressed, one way or the other. People learned. People moved on. Sure, there was a lot of griping about a brittle ecosystem, and maybe it was deserved to some degree, but … truthfully, the only comments that would have been worth paying attention to were the ones that tried to fix the problem, or at least acknowledged that it was only a problem.

More closely to home, some of my infrastructure tooling at work failed thanks to a Docker upgrade; Docker itself didn’t fail, but a tool that used the Docker daemon to build images started failing.

One of the comments from a fellow coder: “This is why I don’t like the JVM.”

My response – kept to myself, I hope – was not entirely positive, let’s say. That’s a dumb response. That’s a knee-jerk response; it doesn’t acknowledge that infrastructure tools are programmed, too, and things happen.

Docker changed; the tooling is changing, too; it just takes time. The timing’s inconvenient, sure (I changed the build process to avoid that mechanism), but it’s just a problem. It will be fixed. The bug was reported. Information is being exchanged. The tooling will be fixed, because there’s no way I’m the only person who’s encountering this bug (and I’m not; others have reported it as well.)

But the proper reaction is definitely not to decide that the entire ecosystem associated with what you’re working with is broken; after all, other ecosystems are going to have their own bugs, too.

The solution is to communicate and participate; use a workaround (like I did) if you have to, and sometimes you do, but don’t abandon the process. Report. Heck, patch if you can.