Open Source is Software Feudalism

I’m a big fan of open source. One of the things I have enjoyed since my departure from Microsoft is being more involved in the open source community. I have been contributing changes to projects that I am using as well as trying to make more of my code open source. Of course I’ve been relying on Github heavily as most people do, and have been enjoying it quite a bit.

One problem I’ve been noticing as a member of the Open Source community is that while Open Source projects claim to be open and free they do still have owners and controls which can limit participation.

I was discussing this with my good friend Leo and he called Open Source “Feudalism with infinite land”. Because an open source project stakes a claim in the land of software-needs and then controls it tyrannically. It’s easy to see a lot of parallels where this analogy makes sense. Such as the fact that projects have owners who have power over its community of users. Popular projects are like duchies, you are able to claim “land” in popular package managers such as npm. Once you’ve branded your project and claimed the names you effectively control that territory forever.

To take the analogy a little further the GPL license itself is a little bit like the Catholicism of this feudal system, with Linus Torvalds as its Pope. It’s the one true religion that all believers should conform to, even though most of us are secretly MIT heathens in our day to day lives. Furthermore, like the vow of chastity which is used to consolidate the inheritance of priests’ wealth, the viral nature of the GPL license is designed to ensure that more IP is slowly inherited over time by church of Open Source.

Now I don’t want to slam Open Source too much but it would be really nice to see it turn in a more truly free and open direction, away from tyranny and more towards anarchy. But what would this even look like?

For starters I think there should be a feature for any open project in Github to allow the community to control the owners of the project. Meaning, for a given project there should be a voting mechanism, which periodically allows the community to add or remove people from the set of project owners.

Similarly there should be a mechanism for individual Pull Requests where the community could vote on said PR to influence its acceptance.

Furthermore, a culture where people are happy to transfer ownership and view it as a healthy way to vitalize projects and limit power consolidation is necessary.

Additionally, I would like to see a feature where a project can, in a structured way, declare what kind of contributions they are seeking. From owners, to developers, to design work, to specific features and bugs. There should then be a master list where anybody could go and see this list of work sought and after a period of time automatically join into a project they find interesting.

Projects that go stagnant would have ownership roles automatically go up onto the board. Ownership roles that have more applicants than are available would have community based voting before the role is granted.

Most of these ideas are just things I came up with this morning (with the help of Leo of course). So I’m not saying they’re perfect or even well thought out. However I think the general principal is sound, which is that there is a problem of tyranny currently in Open Source and I would like to see it move into an even more open, anarchistic direction.

Executing shell commands from node.js on Windows

If you’re on Windows and driving node.js through the shell that came with git for windows instead of CMD, it can be surprisingly difficult to invoke shell commands from javascript. The child_process.exec function will always call into CMD.exe instead of bash and if you try to use spawn it will expect you to parse your command into an array as well as escape strings and use backslashes.

It was surprisingly difficult to execute an arbitrary shell command for me so I just wanted to share the small amount of code I ended up writing to achieve it.

Note: this assumes you have Git for Windows or some other shell which you are then running node from.

var spawn = require('child_process').spawn;

function run(cmd, env, callback) {
    if (!cmd) return callback();
    var p = spawn('sh', ['-c', cmd], {
        env: env,
        stdio: 'inherit'
    p.on('close', function (code) {
        if (code !== 0) return callback(new Error('Command failed', code, cmd));

module.exports = {
    run: run

How I Learned to Stop Worrying About Cross-Platform and Love Electron

Last weekend I gave a presentation to the Twin Cities Code Camp about Electron called:

How I Learned to Stop Worrying about Cross-Platform and Love Electron

It went pretty well I think, there was more content than time permitted me to go through but for the most part the presentation went along smoothly. I made a kind of interactive demo / tutorial application in Electron that I used to give the presentation, which can be found here:

If you want to play around with electron or use the tutorial yourself to give a presentation feel free! Also please feel free to send a PR if there are any improvements you’d like to see.

The Composition Design Pattern

You may have heard the expression “prefer composition over inheritance“.

But what does it really mean? What’s wrong with inheritance? Even the Wikipedia article on composition over inheritance is using classes and inheritance to explain composition. If composition is so much better than inheritance (at least sometimes), then why do we have to explain composition in terms of inheritance? And why do most modern programming languages and platforms support classes and inheritance syntactically but not composition? What would a programming language even look like if it had syntactic support for composition? Furthermore, what even is the design pattern for composition?

Many of the examples you see from cursory searches online simply show one class containing references to others and that’s about it. This kind of overly simple example seems to acknowledge the problem without really explaining the full solution and it’s completely framed in a context of inheritance. Simply introducing classes containing references to other classes doesn’t give us enough information to establish a pattern and it ends up raising more questions than it answers.

One really good example of composition can be found in Unity3D. Composition in Unity3D is a first class concept that runs very deeply into the built-in game engine that drives everything that Unity does. After studying it for a while I would like to use the patterns of composition found in Unity as a basis for our design pattern and our hypothetical programming language.

Aspects of the Composition Pattern

In a compositional system you therefore need at least two kinds of Types:

  • Object
  • Component

The Object in a compositional system is not the same as an Object in an inheritance based system. An Object in a minimal compositional system has the following attributes:

  • It may have a name
  • It may posses child objects
  • It may have a parent object
  • It may contain named components
  • It can send messages to components

A Component has the following attributes:

  • It has a reference to the Object it is contained by
  • It may have data
  • It can handle messages

Simple Example

If we were to design a minimal version of this system (in C#) it may look something like this:

For a more robust example I highly recommend studying Unity3D in detail. However the question I am asking is what would a system like this look like if it was not framed in the context of classes. How would it look if it were to have syntactic support in a language instead of simply implemented as a design pattern in terms of inheritance? I don’t fully know the answer to this question but I have been experimenting with some ideas and would like to have a discussion around them.

The first thing to realize with this system is that instead of designing Objects up front with static definitions like classes you can only instantiate them and you can only design their hierarchy.

Components are more interesting and do have a static definition. They contain state like a class which means they fulfill the OO principle of encapsulation. They may handle messages of any shape which also means they are polymorphic but they are not inheritable in this system. You may be tempted to add inheritance to components at this point but I believe that this is unnecessary and a mistake. The reason for this is that inheritance is basically just another kind of relationship but it is one that has a much higher degree of coupling between objects. There are a variety of reasons why this form of relationship can cause problems. One is the lack of abstraction and thus isolating the unit for test can become very complex and costly. Instead of using inheritance simply break out shared behavior and state into even more, smaller and more focused components.

A composition system like this is actually similar to the DOM you would find in a browser. The primary differences are that in this case it would not be tied specifically to a single domain (e.g. the domain of laying out and rendering documents) and instead of using an event system it uses message passing. In this way composition allows us to be extremely loosely coupled without requiring extra abstractions.

I can imagine systems where, instead of having a component keyword in the language, you compile entire files into components similar to the way you would compile an entire file into a module in a CommonJS system such as node.js. Your main app would essentially setup your starting objects the rest of your files would be Components. These ideas are very powerful I believe. The game industry has known about them and has been perfecting them for quite some time now, while the rest of the programming community appears to be largely unaware as far as I can tell. I would love to see some experimentation with these ideas in non game domains and find out what the community can come up with.

New Job at Evolve

I’m happy to officially announce that I have accepted a job at a local start-up here in Minneapolis called Evolve.


We’re going to be a very small crew, working closely together to bring Evolve to the next level. I’m extremely excited to take this next step closer to my original passion: video games. I am also very excited to learn more about start-ups and what it takes to put them together and make them successful.

And if you want to play some games head over to my Evolve profile and add me as a friend!