Making Our Open Source Communities More Like Starfish

Starfish are incredible animals.

Perhaps you never took the time to fully appreciate the complex simplicity that is a starfish. You may have enjoyed seeing them at the beach or the aquarium. You may have appreciated their beauty and their stillness, but underneath that beauty and that quiet tranquility, is a great deal of insight waiting for us to uncover.

Unlike us, starfish do not have a central organizing brain that manages executive decision making. Rather, starfish operate on the ultimate distributed system.

An entire new starfish can be grown from any single limb. Why is that? Because there is no one place, no one seat, where all decisions for the organism happens.

Starfish are also keenly aware of the resources in their environment. Which leads us to the next incredible fact. Starfish don't have blood to circulate nutrients and the like through their system. What do they use instead? Seawater!

Ocean water is, well, abundant in oceans. Why not take advantage of that resource and adapt accordingly?

Starfish, in their resourcefulness, awareness, and decentralization, are exemplars for our open source communities.

How so?

Ori Brafman and Rod Beckstrom in their work, The Starfish and the Spider: The Unstoppable Power of Leaderless Organizations, demonstrate several key insights to be gleaned from the biological wonder of starfish.

I believe they can be encapsulated in the following four principles for open source software communities and the people who are invested in them:

1. Decentralization
2. Keeping it Simple
3. Adaptability
4. Everyone Contributes

Decentralization

"When you give people freedom, you get chaos, but you also get incredible creativity."
- The Starfish and the Spider

Removing overly restrictive leadership structures and processes can be terrifying. As a community organizer and someone who has maintained several open source projects I can very much relate to that.

Do you know the people who care about your project? How will you enforce pull request standards? Code conventions? Testing coverage? Who will make sure every feature request is properly vetted and reviewed?

Decentralizing decision making does not mean that decision making does not happen. It means that there is not a single person or a few people deciding everything.

At Orbit we firmly believe that the future of community is distributed and decentralized.

When the character of Aaron Burr sings "I want to be in the room where it happens" in Hamilton, he is striving to be part of a classic leadership model where there are a few folks in a backroom somewhere who decide it all. If you want to have a voice in that process, you need to be in "the room where it happens".

Our open source projects should not have backrooms for decision making.

Tools like GitHub Discussions, and vehicles like committees, can help distribute and make transparent that load. A clear, simplified and streamlined process to join those work groups or committees is integral for decentralization.

Radical formulations of decentralized decision making removes the veto from "the leaders" and relies on communal consensus to discern project goals and aims. You may not be ready for that step, but you can certainly create committees/working groups that distribute the tasks and the decisions to the greatest number of people.

Keeping it Simple

As software developers many of us are familiar with the acronym of K.I.S.S., "Keep it Simple Stupid" or "Keep it Stupid Simple". We know what that means for our code, but what does that mean for our projects themselves?

There are three fundamental questions you should be asking regularly of your community:

What do people need to know to be involved and be successful?
‍

What do people need to do to get involved successfully?
‍

Why should people care?

These three questions require that you do your homework. The keeping of good notes, tracking activities and engagement, and understanding the overall health of your community is integral to its success. Tools like Orbit empower you to do that.

Each of those three questions necessitates clarity and proper process. To help someone move from a casual observer of your community to a participant, you must know the pathways they can traverse. For an open source software project that could be a process like:

Consumer of the project -> Raise an issue -> Asked to code review proposed solution -> Join Discord server -> Invited to a working group

What your pathways will look like are highly dependent on the unique circumstances of your community. Every single community, though, has them. However, not every single community is aware of what they are. If you are not aware you can't move people through them, and you can't track their success in engagement.

Adaptability

Starfish left blood behind and embraced seawater because of its abundance as part of the evolutionary process.

The currents around us are always changing. It is often said that there is no treading water. You are either swimming or you are sinking. The difference is your ability to adapt to the ever changing circumstances of your environment.

Case in point: When is the last time you visited a Blockbuster Video?

The lifecycle of open source software projects often follow a certain trajectory.

First, there is a small group of people or even a single builder who invests a tremendous amount of time and effort into it.

At some point, it catches the interest of a larger group of people, and builds an organic community of users and developers. Then, either it joins the list of incredibly popular projects and becomes a global developer phenomenon or it stays for a while at that stage of modest growth.

Lastly, as it happens in every other sector in society, so too does it happen to open source software, interest starts to wane. Indeed, in software it seems to reach this stage even more quickly than in other areas. The project is still vital to a lot of people, but it is no longer trending. We can all think of tooling that fits this category.

What an open source project needs at each of these stages is going to be different. The resources available to it will also be dramatically different at each stage. The project that knows its internal and external resources at any given time, and can pivot based on that information, is one with great potential for longevity.

Everyone Contributes

If you want user contributions, build platforms that are familiar and easy. Lower the barriers to participation; focus on helping users to understand what you want from them
- Nieman Journalism Lab

It almost can go without saying that communities that involve the maximum number of people are more likely to succeed in persevering, growing, adapting, and remaining relevant for the long term.

A culture of contribution underpins everything else. Open source projects that see the same people raising every issue, opening every new pull request, suggesting every new feature, are not indicative of a culture of contribution.

The circles of engagement should be broadening not remaining static.

From the ground floor level, deep in the weeds, it can be hard to know if your project's circles are growing. You often need to take a balcony perspective. This is where tracking and analyzing all activities and members becomes vital. You can do so with elaborate spreadsheets, or you can use automated tooling to make that possible and save you some headache.

Starfish in their quiet, still and contemplative ways can end up teaching us quite a lot on organizing our open source communities. What we have uncovered is only the beginning.

The Starfish and the Spider: The Unstoppable Power of Leaderless Organizations, contains a lot more valuable insights that are applicable to our communities.

If you are interested in these sort of conversations and discovering ways to continue to grow healthy open source communities consider joining us on June 30th for a fireside virtual chat with Brian Douglas, an open source community leader, mentor and developer advocate at GitHub.