Open-source as a project model for internal work

Kevin Lamping

Note: An extended-length recording of the talk is available on YouTube

In March I have the honor of presenting the opening session at Space City JS. The talk, titled 'Open-Source as a Project Model for Internal Work', will cover a topic I've been brewing over in my mind for years.

Several years back, I was having frequent conversations with a past colleague and good friend of mine about the subject. In our role at the time, we were tasked with developing and supporting an infrastructure framework for over 300 developers. His focus was on the server-side, mine on the front-end.

During our conversations, we began to grow an interest in how open-source projects run their show. We were specifically interested in some key parts:

  1. Most open-source projects don't have dedicated, co-located teams. How do they cope?
  2. How do they get people to volunteer their time?
  3. How do they support their ever growing user base while staying adaptable?

It's hard to remember the specifics of the conversations, but the idea remains clear: Open-source projects face problems that, when you think about it, many internal projects face within companies.

  1. Even if everyone is in the same office space, at a certain user base size, you're essentially working as a distributed team due to space constraints.
  2. Teams will always be understaffed. Consumers of your project will likely be very busy with their own work and will have little time for contributing back.
  3. After a certain number of users, you won't be able to keep up with the constant flow of "drive-by" questions and e-mails. You must balance time spent supporting your fellow teams with time spent developing new features.

From these discussions, we started applying the open-source model to our internal work. We tried using more written communication, so that people could more easily access project information and documentation without having to set up meetings with us.

We also realized that switching to version based releases that projects "pull" down would allow us a much more iterative approach to development, compared to us pushing releases on top of their in-flight projects and causing a mess.

Additionally, we flirted with the idea of implementing our own flavor of the Node Stability Index, to help promote a healthier product lifecycle for introducing, supporting and deprecating functionality.

Over the next few weeks, I hope to share in much greater detail how we implemented these ideas, and to dive in to related thoughts I've had on the subject since parting ways with that specific project. Hopefully the information can help you better support the team your working with, even if you're not shooting for the moon.

As I write the articles, I'll post links to them below. Here's what I have so far:

  1. Empathetic Infrastructure Code Management: An Introduction