Tag Archives: open source

General

Governance Part 4: Creating Intentional Culture

A row of adorable, fuzzy baby ducklings sitting on a log in the edge of a body of water.

This is the fourth blog post in a series about open source project governance, so you should consider pausing and reading the other posts about why governance is important, defining governance, and pathways to leadership before reading this one.

Defining your governance / decision-making processes along with pathways to leadership are key to creating an intentional culture for your project that encourages participation and contributions from others. Having a scope, vision, and values (sometimes called a charter) for your project can help people understand what is / is not in scope for your project to encourage people to work on contributions that are most likely to be accepted and avoid wasting time on contributions that aren’t aligned with the project. This also helps to avoid issues and misunderstandings later by helping align the expectations of all community members. By setting expectations and clearly documenting them, you set the stage for creating a healthy and sustainable project over time.

However, just documenting your governance process and setting expectations in writing isn’t enough. You should also be role modeling good behavior and helping others understand what behavior is appropriate within your project. It’s important to remember that tolerating bad behavior unwittingly sets the expectation that this behavior is acceptable in your project, which can drive new contributors away, so addressing concerns promptly before they can get out of control or become a crisis helps set an intentional culture and improve sustainability of your project. A code of conduct is a good starting point for these conversations, but it’s also important to think about how you plan to approach code of conduct issues and how things like remediation and education can be a first step to help people meet the expectations of your projects, instead of taking an enforcement first approach. 

Unfortunately, some projects eventually run into issues that can’t be resolved via remediation or education, and in these cases, it may be necessary to remove someone from your project. Your governance documents should have a provision for involuntarily removing someone from your project, even if that person is in a top leadership position. I watched a project struggle with bad behavior for months while waiting for a steering committee member’s term to end because they didn’t have a process for removing that person. We always hope that we never need to use the process to remove someone, but you’ll be glad that you put it in place now if you ever need it in the future.

Having your ducks in a row with robust governance documentation that incorporates your code of conduct, charter (or similar statement of mission, scope, and values), and includes clear processes for dealing with conflict can help make your project more sustainable over time. 

Resources:

Photo by Mike’s Birds on Flickr

General

Governance Part 3: New Contributors and Pathways to Leadership

Black ladder going through a slot in a canyon with reddish orange rock.

This is the third blog post in a series about open source project governance, so you might want to pause and read the first post about why governance is important and the second one about defining governance before continuing.

It can be difficult to get people to contribute to your open source project, and unfortunately, there is no magic or one size fits all solution. Many projects struggle to find people who will actively participate and continue to participate over the long term. If it was easy, you would already have all of the people you needed to maintain your project, and you wouldn’t be reading this blog post. But not all is lost, there are things you can do to increase the chances of growing your contributor base for your open source project.

Good contributor documentation, especially for new contributors, is the first step toward bringing new people into your project in a scalable way that requires less time from busy maintainers. If this is well documented, new contributors can get started with a minimal amount of help from existing maintainers, which can save you a lot of time in the long run and reduce frustration for maintainers who are answering the same questions over and over. At a minimum, you should have instructions for everything that is required to get your project up and running in a development environment along with the process and guidelines for submitting a new contribution.

Defining the roles and responsibilities for contributors, reviewers, and maintainers can help with recruiting new people into these roles. You can think of this as a ladder because contributors climb up to become reviewers and those reviewers can become maintainers. What’s important is to have some documentation so that people understand how they can climb the ladder and gain more responsibilities within the project.

A contributor ladder usually outlines the different contributor roles within the project, along with the responsibilities and privileges that come with them. Community members generally start at the first levels of the ladder and advance up it as their involvement in the project grows. This helps set expectations for the roles and encourages people to think about how they might take on increasing responsibility within the project. As you get more of the people moving into maintainer roles, you can reduce the workload for the existing maintainers.

As a maintainer, when you are reviewing contributions and engaging in the community, think about and notice when someone is making solid contributions, which can help you decide who you can encourage to contribute more or maybe find someone who could move into a maintainer or other leadership role. Reaching out to someone and acknowledging their work while encouraging them to do more can help quite a bit with growing your contributor base. Sometimes people just need a bit of encouragement, and you can ask them for specific things that you know they are good at. 

You should also be thinking about how you can move people into leadership positions to be responsible for activities beyond writing code, like documentation, community management, marketing, and other important roles. These activities take up valuable time from maintainers and someone with expertise in these roles can often do these activities more efficiently and with higher quality than a maintainer without that specific expertise. You can add these to your contributor ladder and promote people into maintainer roles to be responsible for things like community management, documentation, program or product management, marketing, and more as your project grows to need these roles. 

Maintaining an open source project is so much work, and many maintainers are overworked, exhausted, and burning out. The best way to address this challenge is by finding people who can reduce your workload, but it’s hard work, and it takes time away from the day to day activities now, which can be hard to justify when you feel like you’re barely keeping up as it is. In the longer term, spending at least a little time on things that can help you recruit and keep new contributors that can eventually become maintainers will be worth it. You don’t need to do everything at once, and many of the suggestions above can be taken in small steps, one at a time. Spending just a little time on something to grow your contributor base and recruit new reviewers and maintainers is a great way to start.

Additional Resources:

This is the third post in a series about governance, so stay tuned for more blog posts about creating intentional culture and project ownership.

Photo by Paulius Dragunas on Unsplash

General

Governance Part 2: Defining Governance

One leaf on a stem in a glass vase with water with a white table and white background representing simplicity.

This is the second blog post in a series about open source project governance, so you might want to pause and read the first post about why governance is important before continuing with this one about defining governance.

In general, you should start with the simplest possible governance model and only move to something more elaborate when your project evolves to the point where the complexity is needed because otherwise you create more overhead and extra work when that time would be better spent on project development, rather than governance processes.

If you don’t already have your governance and decision-making processes documented, the best place to start is by documenting and formalizing what you are already doing when you make decisions for your project. Who currently makes decisions and approves contributions? Who provides input? How can this be improved? How can you include new people in this process over time? What works well already? What processes could you improve?

Most projects can start with what is often called the maintainer council model, which is the simplest form of governance. This is where your existing maintainers make the decisions in the project, often by consensus, but there is usually also a provision for calling for a vote in certain cases. Voting usually comes into play when there are disagreements that cannot be resolved via consensus, or for big decisions that impact the structure of the project, like changing the governance model or removing someone from the project.

Some key elements that should be included in your governance documents:

  • Leadership selection processes
  • Processes for removing people from the project (both voluntary and involuntary)
  • Link to your Code of Conduct
  • Voting – actions that require a vote, whether it requires a simple majority (>50%) or a supermajority (2/3), and who gets a vote.

Additional Resources:

This is the second post in a series about governance, so stay tuned for more blog posts about pathways to leadership, creating intentional culture, and project ownership.

Photo by Sarah Dorweiler on Unsplash

General

Governance Part 1: Why is it important?

Hand holding an old fashioned, silver pocket watch on a dark background

Sustaining projects over the long-term can be a challenge. Many maintainers and contributors are overworked and have a number of competing priorities, so they don’t always have the time to focus on ways to improve sustainability. Being proactive about governance and related topics before something escalates into a crisis can make your projects more sustainable and reliable. 

A lot of people think governance is just extra paperwork, but this isn’t true of good governance, which is really about defining your decision-making processes, setting expectations, and making it easier for people to contribute to your project. Ultimately the focus of open source project governance is on the people. The roles we play, our responsibilities, how we make decisions, and what we should expect from each other as part of participating in the community.

Having clear rules about how collaboration occurs, how decisions are made, and what types of contributions are in or out of scope helps community members make contributions that are likely to be accepted and embraced by the project. This facilitates the creation of an intentional culture, and helps avoid wasting maintainer’s time with contributions that aren’t aligned with the project. It also helps create pathways to leadership where other people can better understand the process for moving into leadership roles along with an intentional process for how the project promotes people into leadership.

The tricky thing about governance is that it needs to be proactive. The time to work on governance is at the start when things are going well. If you wait until there is a crisis of some sort within your community, you might not have the right processes for dealing with that crisis, and when a project is in crisis, it will be more difficult to come to an agreement about governance.

Here’s a short, 4 minute video introduction to open source project governance to get you started:

This is the first post in a series about governance, so stay tuned for more blog posts about defining governance, pathways to leadership, creating intentional culture, and project ownership.

Additional Resources:

Photo by Pierre Bamin on Unsplash

General

Demonstrating Organizational Value

Yellow shocked emoji with dollar sign eyes

We just launched the latest in our Practitioner Guide series with a guide on Demonstrating Organizational Value. As you can imagine, this is a big and difficult topic, so this is our most ambitious guide so far, and it’s our first guide outside of the “Getting Started” series of guides.

The idea for this guide came about as a result of several conversations with Bob Killen around the time of his KubeCon talk: Why is this so hard? Conveying the Business Value of Open Source (slides and video) along with the White Whale talk from the Linux Foundation Member Summit. After seeing these talks, I knew that I wanted to work with Bob to turn his ideas into a practitioner guide.

I’m co-chair for the CHAOSS OSPO (Open Source Program Office) Working Group, and the topic of how to demonstrate the value of our work in open source has been a popular topic of conversation since we started the group. However, given the current financial climate and the number of OSPOs that have been the targets of recent cutbacks and layoffs, this feels like a particularly important topic right now.

Creating an open source contribution strategy can help organizations frame their discussions with leadership to demonstrate the value of their open source efforts in ways that resonate with leadership. At a minimum, the open source strategy should contain details in the following areas, which are each addressed in the “How to Take Action” sections contained in the guide:

  • Supporting your organization’s goals
  • Determining which open source projects are the most critical for your organization
  • Assessing open source project health risk
  • Prioritizing within your organization’s limited resources
  • Measuring & framing value

I hope you find this guide useful as you think about how to demonstrate the value of your open source initiatives within your organization!

Related blog posts:

Photo by Farhat Altaf on Unsplash

General

The Impact of Funding for Sustainable Open Source Projects

Messy pile of different types of paper currencies from around the world

I recently blogged about the challenges of sustaining open source projects and communities over the long-term and what companies can do to help. Much of the critical infrastructure that we all rely on is made up of open source projects that lack the resources to be properly maintained over the long term. One way to address this issue is by providing funding for maintainers and projects, but that’s not always as easy as it sounds. Money can introduce new challenges for projects as they figure out how to distribute those funds and decide who does or doesn’t get funding. The groups providing the funding also need to be able to measure and communicate the impact so that they can continue to justify providing funding in the future. 

At the recent Open Source Summit in Denver, Georg Link, Andrew Nesbitt, Alyssa Wright, and I discussed some of these challenges around funding. Here’s the video from our panel discussion.

For the past 18 months or so, I’ve been consulting with the Sovereign Tech Agency a few times a year as one of their external experts to provide input into selecting projects to receive funding, which has led me to better understand some of these challenges. I’ve been working on measuring the impact of funding with Paul Sharratt from the Sovereign Tech Agency / Fund along with Cailean Osborn and Mirko Boehm from the Linux Foundation who have been working with the Next Generation Internet (NGI) initiative at the European Commission (EC). We wrote a paper on this topic, which eventually led us to start the CHAOSS Funding Impact Measurement WG. Anyone interested in measuring the impact of open source project funding is welcome to join our working group meetings, so I hope to see you there!

Additional Resources:

Photo by Jason Leung on Unsplash

General

UN Open Source Week Part 2: Digital Sovereignty and Resilience

Row of flags in front of the United Nations Headquarters in New York on a sunny day with green bushes in the foreground and skyscrapers in the background

This is the second, and final, blog post about United Nations Open Source Week, so if you didn’t read part 1, United Nations: OSPOs for Good Day, you might consider pausing and reading that post first, since it provides more context about the event and why the UN cares so much about open source software.

As part of the week’s activities, there were several side events on Friday, and I spent the day in the Digital Sovereignty and Resilience side event. This blog post has a short summary of the presentation, panels, and discussions, so these don’t necessarily represent my views and might contain factual errors. Speaker names and abstracts for each session can be found on the United Nations Open Source Week website on the side events tab.

The Digital Sovereignty and Resilience side event started by looking at ideas for building a sovereign digital workspace with short presentations about various open source workspace solutions. The French Interministerial Digital Directorate (DINUM) talked about how they have collected a set of tools (Le Suite) for their use and are also collaborating with Germany’s Zendis. There were also short presentations about specific projects that can make up a workspace solution: Matrix, Grist, and IREX (Institut du Retour d’EXperience). But it’s more than a set of tools, we need a better vision for how to build an open source digital workspace and integrate it across governments. It’s not about one tool to beat the others, but about working with companies and contributing within open source communities to help make sure that we have integrated solutions. This requires funding, especially when companies are involved. The UN is trying to coordinate across technologies to integrate solutions and improve collaboration, and they are also looking at potentially hosting some open source solutions – starting within the UN, but this is early days for this work, and we would need to expand it beyond internally within the UN to across countries. 

The next session was all about securing the supply chain through global collaboration, which is something we talk about all of the time within OSPOs and in the corporate world, but in light of the CRA, this is increasingly important for all of us. We need more collaboration across governments and other stakeholders (e.g., companies, organizations) to make sure that we can all work together to understand and improve the security of our open source software, and this is something that the UN might be able to help facilitate. We collaborate now, but it’s pretty ad hoc, and we need better public / private relationships / partnerships. We need more funding to be able to sustain these efforts beyond what groups like Alpha Omega and STF / STA are already funding for security initiatives to improve open source security. 

The folks from the Sovereign Tech Agency led a session called, Invisible Work, Critical Code – The Role of Maintainers in Open Source Digital Infrastructure where they talked about how open source is like a sewer, critical infrastructure that needs to be built and maintained over time. In the case of something like public water systems, railways, libraries, schools, and roads, these are usually maintained by governments paid for by our taxes. Digital infrastructure is fragile (obligatory XKCD), despite being the foundation of the digital economy, and governments should also be investing in critical and essential open source digital infrastructure in support of them as public goods. This was followed by a panel, which talked about how maintaining projects go way beyond just code and include things like conflict resolution, mentorship, communication, building community, and other invisible labor. Being inclusive of people with different needs helps level the power imbalances that we so often see in open source and in software in general. Being welcoming for the most vulnerable people creates spaces where people want to contribute and participate. Software is too important to be left to just developers. 

The final session in this Friday side event is Fostering Resiliency in the Digital Public Infrastructure (DPI). DPI is like a public library and needs to be resilient enough to endure over time and across administrations and economic conditions. We need to think about how we can ensure that the 100,000 components embedded in our software are safe and secure when many of these components aren’t actively maintained. This impacts us on a societal scale because these components are all part of our DPI. People need to be able to depend on DPI based on their use case to avoid societal harm. DPI and open source together allow us to recombine and reconfigure to use the software in ways that allow governments to better support their constituencies. Data integrity and trust are important for DPI across the many stakeholders involved in building and maintaining the software. Risk identification, risk understanding, and risk mitigation are steps toward building resilient DPI. Finally, there was an overview of ApeiroRA and the NeoNephos Foundation for next generation cloud infrastructures and services that strengthen digital sovereignty for Europe, but that could also be used by other regions. 

I really enjoyed the time I spent this week! The best part of the week were the conversations, and it was good to get out of my little open source bubble to talk to and better understand people who are working in contexts completely unlike my own. The UN did a great job of bringing people together from industry, government, not for profit organizations, and other groups from around the world with over 40 countries represented, including many from the global south. If we truly want to make open source software better serve the needs of our global communities, we need to collaborate across all of these groups, so a big thank you to the UN for bringing us all together!

General

United Nations: OSPOs for Good Day

United Nations: Welcome to Open Source Week #UNOpenSourceWeek

I was thrilled to be invited to attend the United Nations Open Source Week in New York joining a few hundred people from over 40 countries to talk about open source. 

The OSPOs for Good day on June 18, kicked off with a keynote by Amandeep Singh Gill, Under-Secretary-General and Special Envoy for Digital and Emerging Technologies, UN-ODET, who talked about how the UN sees open source as a foundation for digital transformation, but one that requires the UN to move beyond its historical focus on governments to engage multiple stakeholders. Looking around the room, you could see this reflected in the event attendees who represented governments, companies, universities, not for profit organizations, individuals, and more. Later in the day, Dmitry Mariyasin, Deputy Executive Secretary, UNECE, talked about how he sees open source as an inspiration for how the UN can operate more broadly in their role to create public goods using digital solutions to improve sustainability and increase transparency and trust. 

You can watch the livestream of the event, but here are a few highlights or common themes from the OSPOs for Good day.

  • Historically, many open source conversations were about cost savings, but this wasn’t the case at this event. The conversations have shifted to collaboration, innovation, and using open source to build trust.
  • Several of the people representing governments talked about how having an OSPO helped them build connections to other people involved in open source within their organizations while also allowing them to build connections and partnerships to collaborate and learn from others. Many countries view open source as being critical to their success as a country and in serving the needs and improving the livelihoods of their people.
  • The newly formed Trinidad and Tobago OSPO and Kenya OSPO are part of an initiative to create a replicable, scalable model of OSPOs across the global south with a goal of serving countries beyond just their governments to promote open source. 
  • Governments want to use open source, but struggle with procurement processes, which requires different policies to contribute, add new features, and maintain open source projects. Governments have been more willing to fund new features, but often struggle to fund the invisible maintenance of the software that everyone uses, which creates risks for the public that they represent. Germany’s Sovereign Tech Fund (now under the Sovereign Tech Agency) was created as one way to address these risks and make strategic investments in core digital infrastructure.

So far, I’m really enjoying the event and am looking forward to the next two days!

Update: I’ve followed this up with a second blog post: UN Open Source Week Part 2: Digital Sovereignty and Resilience.

General

Companies Can Mitigate Sustainability Risks

A bunch of people having a great time in a fun picture from CHAOSScon EU

I wrote a blog post earlier this week, Contributor Sustainability Impacts Risk and Adoption of OSS Projects, focused on helping maintainers and open source project leaders understand how companies view risk and how this impacts adoption of their projects. Marko Bevc commented on Bluesky that “there is another side of this coin while companies evaluate the risk (as they should), they should also look into how they are going to support those projects they use (either with contributions or/and other resources – e.g. funding).” This is a really important point, and it’s something that I always bring up when talking to companies about evaluating risk (20 min into this video, for example), so I decided to write a part 2 for the original post, but this time focused on what companies can do to mitigate contributor sustainability risks when adopting open source software.

As part of spending a lot of time over the years thinking about the sustainability of open source projects, I’ve given a bunch of talks (see Additional Resources section below) about how companies can assess the risk and viability of open source projects, but assessing viability is the beginning of the process, not the end. Understanding open source project viability is an ongoing process that needs to be monitored and decisions revisited as projects evolve. As a company, the best way to monitor the ongoing viability of a project is to have your employees contributing and participating within the project. This serves another important purpose beyond just monitoring. By having your employees participating in a project, you can help to continuously improve the viability of that project to increase the chances that it will continue to be viable over the longer-term. 

However, most companies use so many open source projects that you can’t possibly employ contributors to participate in all of them. Generally, I recommend that companies focus their contributions on strategic open source projects that are critical to your ability to deliver customer-facing products or services. For the other projects that you don’t contribute to directly, you might still be able to help them increase their viability in other ways, like through funding, for example. Some companies have funding programs where they fund key dependencies and other projects (e.g., FOSS Funders, Microsoft’s FOSS Fund, Bloomberg’s FOSS Fund). However, it’s also important to think about the impact of providing funding because throwing money at some projects can create friction within the project that can sometimes have a negative impact, while in other projects, funding can make a big difference in increasing viability. We discuss these and other funding issues regularly as part of the CHAOSS Funding Impact Measurement Working Group, and we also maintain a list of resources and research about funding.

To wrap this up, open source sustainability and viability are not something that you can think of as all or nothing. No project is perfect, and each project will have areas within them that are more or less sustainable. Companies can help make projects more sustainable and more viable over time by providing resources, like direct employee contribution and funding for those projects. 

Additional Resources:

General

Contributor Sustainability Impacts Risk and Adoption of OSS Projects

I’ve spent a lot of time over the years thinking about the sustainability of open source projects and the role that contributor sustainability plays in overall project sustainability. When I was co-chair of the CNCF Contributor Strategy Technical Advisory Group, contributor sustainability came up often as a concern for CNCF projects, and the most common question was about how to get more people contributing to our projects. This is a hard problem, but there are some resources at the bottom of this post to help grow your contributor base and increase the sustainability of your open source projects.

What I think many people underestimate is how contributor sustainability is viewed through the lens of risk by companies who are deciding whether to adopt your project. It’s easy to think that your project is different. No one will leave, and the project will be wildly successful forever, but that’s not how many companies think about open source adoption. Some companies think hard about which projects to adopt, especially if those technologies are crucial for delivering solutions to their customers, and would be difficult to replace if the project suddenly wasn’t available. Projects with a single dominant contributor or contributions coming almost entirely from a single company are going to be perceived as riskier and companies will be less likely to adopt or use those projects. This is especially true given the recent wave of companies relicensing open source projects and putting them under proprietary licenses. Put in simple terms, contributor sustainability risk makes it harder to get people to adopt your open source projects.

When I was Director of Open Source Community Strategy at VMware, I would often evaluate the risks of adopting specific open source projects, especially if we were considering building commercial products that incorporated those open source technologies in ways that were critical to delivering products to our customers. Contributor sustainability played a big role in deciding whether we would adopt a project. This was especially true for projects that were more strategically important for us, and which would be hard to replace if the project became unsustainable in the future. Given the choice, we’d select projects with better contributor sustainability, which would be a lower risk for us as a company.

Just last week, I was looking at an open source project where almost all of the contributions came from employees of the company driving the project, and there was a single lead developer who made the vast majority of the contributions and code reviews / approvals. That lead developer and their employer are single points of failure for the project. These single points of failure introduce risk for potential adopters and are likely to cause people to think twice before using a project. If I was a company looking for a solution, I would be unlikely to select a project that could suddenly cease to be updated (including security updates) if something happened to the dominant contributor or the company.

In summary, contributor risk stemming from a single person or a single employer makes your project riskier and less likely to be adopted.

While growing your contributor base is hard work, there are quite a few resources to help you improve contributor sustainability along with gaining a better understanding about how companies think about risk when adopting open source projects. Here are a few of those resources, most of which also have links to additional resources:

Update: You might also be interested in reading this follow up post: Companies Can Mitigate Sustainability Risks

Photo by Jan Kopřiva on Unsplash