<img height="1" width="1" style="display:none;" alt="" src="https://dc.ads.linkedin.com/collect/?pid=12616&amp;fmt=gif">
Try to get to a cooperative system, where people at all levels are actually engaging with each other

Try to get to a cooperative system, where people at all levels are actually engaging with each other

Karissa McKelvey is a product and engineering professional whose work has been crucial for at-risk users including journalists, human rights defenders, and civil society activists living within repressive environments who wish to speak freely online. With her background in political science and engineering, Karissa has delivered public-centered initiatives for open source projects, non-profit organizations, and startups that leverage emerging technologies. Karissa's perspectives and work have been featured in high-profile news outlets such as the New York Times, Wall Street Journal, and NPR. 

Short on time? Here are three key takeaways from Kariss’s interview which outline what she has learned while leading open source projects and how that knowledge can be applied to general software development. 

  • Proper governance can be used to mitigate the risk of having a single person responsible for a module. Most open source software is created by assigning a given module to a single person, which can be very powerful. But it can cause problems if that person leaves the project, so processes need to be put in place to handle the transition to a new owner of a module. 
  • Mission and less oversight attract developers to open source projects. To attract good contributors and convince them to donate their time, emphasize the impact of the project on the open source world or organizations that will benefit from the project. Also, highlight the freedom to take risks and explore new approaches that working on open source projects offers. 
  • Commercial dev teams can benefit from the horizontal structure used in open source software development. The collaborative nature of open source development and the community approach to decision making allow engineers to be more productive and creative. 

 

What follows is a long-form write up of the key topics we discussed in our interview.

In his continued exploration of managing dev teams, Kuba spoke with Karissa who talked about her experiences building and managing teams working as a community on software and what commercial dev teams can learn from the things she has seen and experienced.

 

Volunteers, managing open source engineers, and doing good with software

Partway through work on her Ph.D. and conducting research in data science and complex systems, Karissa dropped out to focus on other things. "I started realizing that there's bigger issues in internet infrastructure that we need to be addressing." After a small stint at Google and some time with startups, she helped found the Dat Protocol. Starting with three people and growing to eight, they raised $1.5 million to fund the creation of their platform. They also added a large number of community volunteers to the project. Now she spends her time as an engineering manager, working with an ecosystem of between 100 and 120 contributors.  As a founding member of the foundation, she also works to grow and promote the organization, and she does similar work at Digital Democracy and is a board member for Code for Science and Technology.

The Dat Protocol Foundation is a non-profit project focused on creating a new peer-to-peer hypermedia protocol. It provides public-key-addressed file archives that can be synced securely and browsed on demand, allowing organizations to cooperatively own and manage the data they are working on. The Dat Protocol allows organizations to share data across the internet without reliance on a third-party cloud provider or needing to pay fees.

“Taking some of the best ideas from git, having the distributed ledger aspect and adding a peer-to-peer network to it.”

The tools are being used by between 30 and 40 organizations that include research groups, universities, and non-profits that require data gathering to be done offline and want to control access to their information. Karissa pointed out that the protocol avoids “link rot” that can be a problem with static data and that privacy is a big part of the initiative.

 

Open source development models and governance

After sharing the background and goals of the Dat Protocol Foundation, Karissa gave her thoughts on the management model usually used with open source software projects—where a single contributor owns a specific module. The problem with that, she found, occurs when that one person has to leave a project. If not planned for, such a departure can slow everything down.

"I don't think that is necessarily a bad thing, to have a dependency on one person, but you have a governance use case where what happens if that person is no longer able to continue. You have to have some ways of moving forward."

She recommends that some type of governance be put in place that is collaborative and has built-in processes for switching module owners when needed. She finds that foundations and community groups already know how to do this, and she simply translates that into governance for the development process. She noted, "I think it is important in those groups to have a variety of voices. That is where a non-profit or community-based space can help mediate all the concerns between all the organizations."

Karissa prefers the community approach, but she listed several other models that she has seen other open source projects use.

  •  No governance. She didn’t recommend this!
  • A commercial company that is involved in—or benefits from—the project takes on the management of the development process.
  • Setting up a blockchain-based platform for finding module owners and contributors and rewarding their effort with bitcoin, like Gitcoin.
  •  Using a “spokes” model where the heads of each organization responsible for a functionality talk and coordinate, then communicate back to their contributors.
  • A model similar to what is used on PostgreSQL where only two people from each organization involved in a project have a say in project planning and priority setting.

She also recommended that people look into the work of Nadia Eghbal to learn more about how different open source projects have managed themselves.

Karissa also mentioned that diversity is something that is needed to improve governance. She observed that “engineering as a whole is very male, white-dominated, especially Silicon Valley. We are getting better as a community at bringing in more voices." And that “right now we are in a flux, where there is more movement, so I'm excited to see what’s happening in the next 20 years or so with this."

 

Attracting contributors and onboarding them once they volunteer

Kuba and Karissa then turned their discussion toward how to attract contributors to open source projects and onboard them once they sign up. She feels that two things help to attract good developers. The first is usually the mission of the project itself. Whether it is adding needed functionality or providing tools to causes they care about, people want to be part of a community that is making a difference. 

The ability to work in an organization that is not managed from the top down is also a draw to many. The freedom and collaboration can be empowering and refreshing, especially for those working in a more structured environment.

“Open source from the first commit is very scary. Especially for people coming from corporate or startup environments. But the value is huge. When people can see your work over time, you actually do better work and you are more encouraged to make things in the way that you want them to be seen by other people.”

When it comes to onboarding, Karissa feels it is not that different from onboarding a new developer in a corporate environment except that the team is more spread out and everyone works more independently. She recommended the following five practices for effective onboarding:

  • Start with a GitHub page that has everything a new contributor needs to know.
  • Have regular community calls where everyone can discuss, contribute, and learn from each other.
  • Set up an IRC channel—even though they can go off-topic sometimes, they can serve as a great resource.
  • Have regular calls with key contributors.
  • Have one-on-one discussions with every contributor to just check in and see how things are going.

 

What commercial teams can learn from open software projects

To finish up their discussion, Kuba asked what the rest of the software development world could learn from how open software projects manage their teams and projects. Karissa felt that the first thing would be to create organizational structures and processes that are more horizontal and less hierarchical. 

"Try to get to a cooperative system, where people at all levels are actually engaging with each other. Less hierarchical and more horizontal. It empowers engineers and gives them more flexibility and excitement to take risks and bring value to the product you are building.”

She then shared how powerful it can be to let technology evolve. Karissa has learned that “listening to engineers and helping them succeed in the goals they have set for themselves and the technology, and empowering them to learn about what is new and what is going on and new approaches, and helping them take those risks, will make them more productive and more excited about what they are working on.” 

To some things up, Karissa made a simple statement about listening and trust.

“Listening and trusting people is something you have to take for granted in open source, and it is something we should be doing in business."



Keep Reading

We are trying to test out new paradigms in terms of how work can get done

You never have a perfect setup, and you never have a perfect process.

Blockchain requires a change of mind on how you code and how you build things.