7 Months

I recently reached my 7th month as a contributor to Public Lab's open source software, a milestone that, amongst other things, brought to my attention that it's now or never to write a blog post.

In the spirit of writing about something that really does deserve a full 7 months of consideration, and still keeps me thinking, I want to shine light on Public Lab's contribution framework.

Open source communities are fascinating to think about because they come in all shapes and sizes - most successful communities share certain commonalities (ie. often called "best practices"), but underneath that their foundations are a testament to achieving a specific ethos and set of goals.

Thinking about Public Lab's contribution framework, founded on 3 simple steps, has allowed me to shape my understanding of the all-encompassing open source community, and what makes Public Lab's sub-community so special.

FTOs

My first PR ever was Oct. 16th, 2018, where I completed what is known in some beginner-friendly OSS communities as an "FTO" (First Timers Only) issue. The labels we use for these, which you might find across Github, are "first-timers-only" and "good first issue". To this day, I have opened 21 of these issues myself.

FTO issues are the glue that holds PL's framework together, and teach us invaluable lessons about open source community and culture. (More on this later).

Workflow

PL follows a 3 step process for initiating new members:

1. A new contributor completes a guided "FTO" issue
2. Then they complete any regular issue, often labeled "help wanted"
3. Lastly, they open their own FTO and help guide a new contributor through it

these 3 steps are incredibly well thought out.

Primer - Openness

One of the most admirable and celebrated aspects of open source is the various acts of kindness amongst contributors in a community. Open source communities make learning an inherently social process, so contributors share an interest in mutual aid and interaction.

Although socialization is inherent, communities still bear the responsibility to facilitate an optimal environment for it. The foundation a community lays down for workflow and culture shapes contributors' interactions.

Public Lab's approach works on the principle of openness. Openness as a paradigm of organization:

This: Openness is an overarching concept or philosophy that is characterized by an emphasis on transparency and free, unrestricted access to knowledge and information, as well as collaborative or cooperative management and decision-making rather than a central authority. More at Wikipedia

Includes this (open source software): 4. computing degree of accessibility to view, use, and modify computer code in a shared environment with legal rights generally held in common and preventing proprietary restrictions on the right of others to continue viewing, using, modifying and sharing that code.

But also openness as a community mantra (ie. receptiveness, kindness, patience).

As the landscape of open source software changes rapidly, with more users joining Github in 2018 than in its first 6 years combined, some communities lead the way in developing a new collaborative model for this uncharted territory.

PL's workflow is exemplary of how this is done. Its approach is multi-faceted, but the focus here is on its ability to cleverly weave community values into its foundational workflow, which carries the most palpable benefits.

Its workflow is a cycle of reciprocity, in which every contributor experiences both ends. From a contributor's first contribution, an air of gratitude starts spreading which they'll carry on.

This is summarized well by the wise words of Google's Summer of Code mentor guide:

"Consider treating every patch like it is a gift. Being grateful is good for both the giver and the receiver, and invigorates the cycle of virtuous giving"

This cycle starts with step 1.

Step 1

provides the opportunity to learn about PL's community culture firsthand while working through an FTO guided by another contributor. This can often be a contributor's first pull request ever, which is one of the toughest milestones in contributing to OSS. Two notable ways PL empowers contributors through its culture of kindness and gratitude:

• Welcome bot: each new contributor receives a congratulatory message on their first PR:

• Every FTO receives feedback from reviewers or maintainers. Commenting something as small as "thank you" makes an impact. Surprisingly, this is not necessarily standard etiquette across open source communities.

A quick anecdote: featuring a community that suffers from the absence of any structured empowerment system

Recently, I stumbled upon some incorrectly translated Russian-language configuration files for a platform-specific i18n community. I opened two PRs. Shortly after, they were merged without any communication exchanged besides these notifications:

It's not that I wanted a gold star. My main problem with this was that the process felt like a side conversation with myself rather than a community contribution, which is not a sought after experience in OS.

Communication is an axiomatic part of a community; this is not a revelation. Any communication is good (a merged pull request is a whole lot better than nothing), but not all communication is the same.

Despite having about 400 contributors and 3,500 stars, the repository still has a number of translation inaccuracies that a single, motivated contributor could fix. It is not meeting its full potential because its large contributor pool is not, well, contributing much after a few initial PRs.

Side note: full respect to this community and what they have accomplished. This anecdote only serves to point out the opportunity cost of expending less resources on contributor engagement, and that contributor participation is not something that's guaranteed to a community.

Step 2

provides the opportunity to rinse and repeat the Git workflow learned from the FTO, with the added challenge and opportunity to create and implement self-directed code improvements.

Step 3

creating your own FTO, provides the opportunity to give back to the community - specifically by guiding new contributors through the same process you just worked through recently.

The result is a community in which the contributors are passionate about helping out: see the free response results of PL's contributor survey.

It also creates an atmosphere of mutual support in which contributors experience being both the supported and the supporter. The implications behind this are important. Contributors that make it to the supporter side and open an FTO typically share a common understanding - that every contributor here is challenging themselves to take on new things and grow, regardless of experience level. The prospect of airing one's work in public feels less intimidating within the community. It is completely reframed as a means of connecting to a community, and materializes one of the key benefits of open source: shared knowledge.

Sustainability

PL's community expansion has largely been self-sustainable so far.

As each new member is expected to add at the very least one new FTO, the community grows exponentially.

As cited in PL's 2019 community report:

"we have grown over 400% in the past year to approximately 500 contributors over the total lifetime of the project."

More importantly, contributors proceed to take on leadership roles, such as joining the "reviewers" team, at a pace that reasonably matches growth. A system of distributed responsibility reminiscent of how a blockchain is governed pans out.

Setting a clear path for contributors to be able to advance to the role of a "reviewer" is an important aspect of openness that leads to sustainability, as it creates an incentive for contributors to become more deeply involved in the community. In PL, this path is the completion of the workflow.

These same contributors always go the extra mile. Off the top of my head, projects spearheaded by contributors in the last few months include: a weekly check-in system (implemented by myself and refined by @bsugar), revamping the community contributor page, updating countless documentation to clarify information for newcomers, establishing a monthly open hour call, and most recently - a system for tracking FTOs (by @gauravano, appointed community coordinator).

The benefit of self-sustainability is critical to understanding that the trend towards openness has benefits previously unreachable with an old leadership model (What comes to mind is a repo advertising "New maintainer wanted" on Github after the old network is exhausted):

Open Source in 2019

PL's community growth aligns with a general growth trend in open source. Consider the 2018 Github stats, such as that 1/3 of all pull requests ever were created in 2018.

As more new contributors look for a fit in an open source community on Github than ever before, openness is a useful mantra to follow in 2019 if an organization seeks to inspire new contributors, scale (relatively) organically, and has the flexibility to restructure.

To ensure the consistent application of a community's desired open source practices, this framework for open governance needs to be built on a tailored and well thought out foundation. Public Lab's simple workflow and emphasis on a positive, supportive culture is a great example of how one community approaches structuring their foundation, managing contributor growth and ethos.