Understanding Open Source Communities

There is no "open source community"

It’s pretty humbling to think about just how much value is freely available to us as developers in 2014. Even a relatively small project stands on the shoulders of giants. Open source code powers big and small components alike: everything from server infrastructure to the most minute stylistic details of our programs.

I’ve emphasized before that, monolithic as this ecosystem may be, it’s built entirely by regular, air-breathing human beings just like you and me. I’ve found “soft skills” to be just as essential as hard technical knowledge. Contributing to open source projects demands an ability to cooperate: setting goals, dividing work, clearly communicating ideas, and resolving conflicts. Coordination is made all the more difficult by the fact that most open source teams never meet in person, span multiple time zones, and contribute in their leisure time, rather than during the workday.

Open Source Microcosms

Open source is composed of an an incredibly rich collection of communities and ecosystems. As an individual developer, “How do I get into open source?” is far too broad a question. Companies like Github have a special role in advancing and building community infrastructure. They think about open source in the aggregate so you don’t have to.

Academically, I find the macro-level role of open source deeply fascinating. But as a developer, these academic concerns are largely irrelevant. The social, historical, and technical intracacies of an individual project far outweigh any shared characteristics of a broader “open source community.” I’d even contend that such a community doesn’t exist at all. A set of many loosely linked communities with shared values does not imply the existence of a single unified community.

Adding Value Through Understanding

As a single developer, your job is to ask: “How can add positive value to one open source project as soon as possible?” If you can’t find one tool you use with a typo in the documentation, you’re not trying. Starting watching the project on Github. Read every new issue and commit, even if you don’t fully understand them at first.

You wouldn’t show up to a job interview without simple preparations like a thorough reading of the job description and basic facts like how many people the company employs and how many years it’s been in business. And yet most novice developers expect to completely skip the observation and learning phase of open source contribution. I think this is why so many people are initimidated by the idea of contributing to an open source project. They see it as a commitment, almost like a second job, rather than a gradual and riskless progression.

Getting on the Rocket Ship

“If you’re offered a seat on a rocket ship, don’t ask what seat. Just get on.” —Eric Schmidt

Even some of the most popular open source project (like AngularJS) are relatively new. The number and pace of projects will only continue to grow as more and more companies identify supporting open source projects as an inexpensive way to improve developer productivity and recruit better talent.

Taking even the smallest concrete step forward today will kick off the cycle of compound growth in both project experience and technical skill. Consider adopting the “don’t break the chain” approach and do something, no matter how small, daily. John Resig, creator of jQuery, has also written about the powerful effect of shipping code every day.

Stop analyzing the problem and just start somewhere. There is no unified theory of open source—only tiny insights you can uncover through persistent experimentation.