Open Source Changing How We Work

November 16, 2012
thoughts random opensource

I may have a bit of an obsession with GitHub right now, and no not GitHub the product, I mean GitHub the company. I’ve posted about how I’ve been inspired by GitHub’s automation and even got my coworkers to watch Zach Holman’s video on GitHub’s automation. And just this week we all sat down and watched Ryan Tomayko’s video on how GitHub does management (hint: it’s not like many other companies).

I promise to not dive into fanboy-ism here, I’m really interested in learning from what GitHub does and how it can apply to other companies. What I do find interesting is what Ryan Tomayko points out in how GitHub works internally. They basically function in many of the same ways as open source projects do. At first it seems a bit strange because of how tied we are to the image of a traditional business with traditional managers, but once you think about it, it makes a lot of sense. Open source has really proven itself over the long term and many very large products work very well this way. Projects such as the Linux Kernel have thousands of people involved in the process and it works very well.

No Managers?

Ryan Tomayko points out that GitHub works without managers as we see them in the traditional sense. Instead having authority over people and telling them what to do, Ryan explains his position more as a guide. Instead of telling others to work on a feature, he must convince them through argument.

This really is very like how things work in open source. Since everyone is volunteering their time working on a project, the only way to really get things done is to convince others in the community that your idea is worthwhile enough to work on. Even if natural leaders appear this way, everyone is free to decide what to work on and when to work on it.

Office Hours

One thing that I’ve seen stressed about GitHub is that they have no fixed hours at all. By taking the approach much like the open source community, they rely on the fact that everything should be asynchronous and electronic so everyone can pick up what is going on at any time. With Open Source this was a necessity because contributors were all around the world, but taking this into account at work has many great benefits.

Being a father of three girls, family is a huge part of my life. When you remove the focus on having office hours, you can remove the tension between family and work and better allow work and family to integrate without causing stress.

Is Anyone Else Taking This Approach?

I find GitHub’s approach to how they work very interesting, but is anyone else out there doing something similar? Just earlier this year, I wouldn’t have been able to tell you, but recently Valve had their new employee handbook leaked. Valve’s handbook is a really interesting read as it lays out how Valve works. And it basically is the same way that people at GitHub works, you are free to choose what and when you work on a project.

In Ryan Tomayko’s video, he actually points out that the reason he did his talk about GitHub at all was because they finally had validation that another large and successful company was approaching management in a similar way.

My Open Source Experience

So if GitHub operates on many of the same principals of Open Source, then I actually have a really good idea of how development works there. Over the time I’ve been with Extend Health I’ve had opportunities to work with the FubuMVC open source project and see this first hand.

When I was working on helping improve documentation to really get things done I had to try and work to get other members of the community to help and contribute documentation. Since I can’t write everything myself and even if I could I sure wouldn’t want to do it myself.

That’s Great and All but We’re Not GitHub

The first thing that went through my head about how GitHub works was “That’s great and all, but we’re not GitHub. There is no way we could ever do what they’re doing”. And after our team got done watching the video, I heard basically the same thing from others as well. At first I was really discouraged that I got all exited seeing two companies I really find exemplary doing new and interesting things and then suddenly realizing that would never work where I am now.

Then I got to thinking about it more and realized that it is ok that we can’t just change everything to be like GitHub. Every organization is different and things work differently for each group. This didn’t mean that we couldn’t learn from how GitHub and VALVe work and improve what we are doing ourselves. This leads to the thought what sorts of things could a more traditional company do to get benefit of the open source style approach? Well, I don’t really know everything but here are a couple Ideas I could come up with.

Open code discussions

If you want your code reviews think about moving the conversation online instead of just in person with another developer. GitHub pull requests work perfectly for this, and you open your code up to a broader audience. With more people looking at your code, you really open things up to some great feedback.

Record everything

Moving conversations online allows us to have a linkable, and documented place to make decisions and have discussions at any time and come back to it later. It makes it easier for new people to get up to speed if they can go back and look at posts, or mailing lists and see what the group spoke about and decided. One of the main tools for this in Open Source is the mailing list. GitHub uses 37signal’s Campfire. I really don’t know what tools work best, but just looking for something that make conversations accessible is a great start.

Be more willing to share

Much of what makes open source fun is that everyone is willing to share their code, stories, and advice with each other. Make it easy for people to collaborate with each other and learn new things. Devs should be more comfortable to share and work with design and vice versa. Just finding ways to help improve communications amongst everyone could be a big help here.

Fin.

So there we have it. I’ve tried to convey some of the thoughts I’ve had in my head the last couple weeks about how both GitHub and Valve work. There really is a lot to take in and a lot more to learn but I’ll leave it at this. I’d love to hear feedback, thoughts, comments about these things as I find them very interesting.