I’ve been giving a lot of thought to community-building within the context of open source software. Ideas have been bouncing around my head for some time and lately I’ve been trying to make sense of them, to articulate them clearly.

The other day I tweeted this:

Haha, yeah, that’s funny, but it’s also kind of true, isn’t it?

I mean, like, Linus Torvalds would’ve been told to leave the CocoaPods community for violating its Code of Conduct. That tickles my brain a bit.

I’ve seen a lot of positive community-building while hanging out with the CocoaPods core team members. I’ve witnessed the organization, as a whole, promote and normalize online, team-based problem-solving in the iOS developer community.

CocoaPods is a dependency manager only in the sense that Apple is a cell phone manufacturer – it’s just one of their many projects.

Watching the team work, I’ve realized that the role of an OSS leader doesn’t necessarily have anything to do with code. Good communities don’t happen by accident, it takes purposeful work and planning.

In a broad sense, their goals are to get people to work together. After all, that's something like a core tenet of open source software. Making a dependency manager is just _one_ way to get people collaborating.

By “more decent,” I really mean “better.” Obviously, “better” is subjective, but I’d argue that (for example) good communication skills, unit testing, and documentation are all important parts of being a good developer.

More general than those specific practices, “better” means the ability to work at a higher level than Apple says is necessary. “Better” means fixing our own problems instead of just complaining. “Better” means contributing to a community.

CocoaPods’ message is really that while the Cocoa Core Competencies are a necessary foundation, they aren’t sufficient to be a good iOS developer.

---

The other day, I was reading over my site, looking for things to spruce it up, and I ended up making a change on my portfolio. I still had my original thoughts on community participation, which were good but unrefined.

I knew then that community participation was important, but I’ve since reflected on what that actually means. I’ve now articulated my definition of good community participation and have worked to adhere to its principles.

To a large degree, I think this has been a natural progression of my existing ideas and background. I already believed in open source by default but now I’ve taken time to reflect on why its important to me.

But this shift has also been absorbed via osmosis from my peers and mentors, a few of whom I even have the pleasure of calling “colleagues.”

One thing in particular that’s had a large impact is Justin Searls’ talk The Social Coding Contract, which discusses the logistics of building OSS communities. I highly recommend it.

After seeing this talk, I made a few big changes to a project I led.

• I transitioned Moya to be its own organization so the project could belong to the developer community.
• Whenever someone had their pull request merged into Moya, I gave them push access to the repository so they felt a sense of ownership.
• I worked with the contributors to define a set of contributor guidelines to make sure the community grows in a positive direction.
• Now I’m encouraging other contributors to review pull requests and discuss features without my input.

As a result of these changes, there are more people reviewing pull requests, planning features, and discussing how to write a better networking library in Swift. The project currently has 1541 stars on GitHub with 45 contributors, spanning 36 releases. It’s been downloaded over ten thousand times.

These aren’t radical or new ideas. I’ve believed in open source by default for some time. But believing in something isn’t enough to make it happen. It takes planning and consistent action.

I’ve been surrounded by other developers trying to make better open source communities, but I’m only now really appreciating the depth of their thoughtfulness.