Tag Archives: sustainability

General

Part 2: Additional Sustainability Topics From the CHAOSS Practitioner Guides

This is the second post in a series, so I encourage you to go back to read the previous post about Building Healthy and Sustainable Projects Using CHAOSS Practitioner Guides if you haven’t already read it. The first post covered the introduction, contributor sustainability, responsiveness, and organizational participation, which were the original 4 guides in the series. 

Shortly after we launched the Practitioner Guide series, we followed up with three additional getting started guides on security, diverse leadership, and sunsetting a project. As I mentioned in the first post in this series, starting with the Practitioner Guide: Introduction – Things to Think about When Interpreting Metrics can help interpret metrics in light of your unique situation. Again, interpreting the metrics and figuring out what they are telling you is only useful if you take the additional step of driving appropriate actions to make decisions and improvements based on those metrics, and each guide provides recommended actions.

Security

Open source project security impacts the health and sustainability for our projects, which ripples out across the entire software ecosystem as dependency / supply chain components. Because security is a complex and critical topic, this Practitioner Guide: Getting Started with Security is designed only to get you started on your path toward improving the security of your project; it is not a comprehensive guide to everything you need to know about open source project security. The guide has suggested starter metrics that include OpenSSF Best Practices Badge, Libyears, and Release Frequency along with additional metrics that might also shed light on the security of a project. 

Recommendations for improvement from the security guide include:

  • Secure your code repository by managing access, implementing branch protection, managing contributions, and more.
  • Create a detailed security policy document (usually in a SECURITY.md file) with instructions for reporting security vulnerabilities along with documenting how the project will respond to those reports, including managing embargoes.
  • Keep your dependencies up to date and use tooling (e.g., Dependabot) to help identify and update your dependencies.
  • Make sure that your security fixes land in a release as soon as possible.
  • Working your way through the OpenSSF Best Practices badge criteria is also a good way to make security improvements.

Diverse Leadership

Without diverse leadership, underrepresented groups may face challenges in participating in and contributing to projects, losing valuable talent and ideas, so a huge thank you to Peculiar C. Umeh who drove the creation of the Practitioner Guide: Getting Started with Building Diverse Leadership! The guide focuses on three key metrics: Board/Council Diversity, Sponsorship (supporting people, not financial sponsorship), and Inclusive Leadership. The data collected can provide valuable insight, but storing, interpreting, and acting upon it requires careful thought to protect identities and be respectful of the people whose data has been collected.

Actions to take include to improve diverse leadership:

  • Start by creating and communicating clear pathways for contributors to grow into leadership roles, which may include creating sponsorship opportunities and transparent criteria for leadership positions.
  • Hold existing leaders accountable for promoting and improving inclusive leadership.
  • Implement programs that encourage diverse representation in leadership and promote diverse perspectives.
  • Regularly monitor and evaluate the diversity of all leadership roles by collecting and analyzing survey data and reporting progress to the community.

This was a challenging guide to write, and it can be a challenge to implement these recommendations. Open source communities are often global and encompass diverse people and backgrounds, so there is a need to avoid imposing a one-size-fits-all approach and be open to adapting strategies to fit the unique needs and values of different groups within your community. Each project should ensure that their practices are inclusive, making all members feel heard and valued, regardless of their background or identity.

Sunsetting (Winding Down and Archiving)

The Practitioner Guide: Getting Started with Sunsetting an Open Source Project is quite different from the other getting started guides because it’s not about making project health improvements or increasing sustainability, but instead about responsibly and proactively shutting a project down when it’s reached a natural end. It’s important to remember that not every open source project can or should exist forever: technologies evolve, corporate priorities change, and people’s interests change. Part of the beauty of open source is that we work in the open as we innovate, and some of those innovative projects will stand the test of time, while others should be responsibly deprecated via a sunset process. The guide looks at several metrics to determine whether a project is still active, Change Requests, Issues New, and Technical Forks, but the guide also covers other reasons for sunsetting a project. 

Once you’ve decided to sunset a project, there are several recommended steps:

  • Communication should start with any existing contributors, since there may be contributors who would like to continue the project. When you decide to sunset the project, this needs to be communicated to existing users in a transparent manner and being clear about the reasons for sunsetting it.
  • Do a code and security review to get it into the best possible shape before archival.
  • Review and resolve open issues and change requests (PRs / Merge Requests), including marking some as ‘won’t fix’.
  • Use the checklists and tools linked from the guide to help with this work.
  • Officially archive the repositories and consider adding the code to Software Heritage for preservation over time.
  • There are also recommendations for handling the special case of sunsetting an active project, which can happen when a company changes strategy or when an individual needs to step away. 

Sunsetting a project is not an indication of failure and should not be positioned as such. Projects have life cycles; they endure for as long as they are needed and then they should be responsibly deprecated when they are no longer needed. Consider providing transition details, and if possible, tooling that helps your existing users transition to an alternative solution if a reasonable one is available. I’d also like to express my thanks to Stefka Dimitrova whose work drove much of the content in the guide and to the team from the US Centers for Medicare & Medicaid Services OSPO who made significant contributions and improvements to the sunsetting guide.

Summary

Improving open source project security and increasing diverse leadership can help a project become more sustainable over time, but when a project has reached the end, it can be responsibly sunsetted, instead of being abandoned. The CHAOSS Practitioner Guide series can help with all of these activities. Come back next week for the next post in this series, ‘Part 3: Determining Value and Viability Using CHAOSS Practitioner Guides’.

As always, if you want feedback or help with open source strategy, sustainability, governance, or related open source topics, I’m available for consulting engagements.

Additional Resources:

As with everything I write, this was written by a human without the use of LLMs or other AI assistance.

General

Part 1: Building Healthy and Sustainable Projects Using CHAOSS Practitioner Guides

Metrics can provide deep insights into our open source projects, but they can also be overwhelming, and because every open source project and every situation is a bit different, metrics require interpretation. And that’s only the first step. Interpreting the metrics and figuring out what they are telling you is only useful if you take the additional step of driving appropriate actions to make decisions and improvements based on those metrics. I’ve been working in open source and using metrics for decades, but for me the metrics have never been what’s important. They are simply the means to an end, a way to make improvements or demonstrate whether we are accomplishing our goals. 

This is why I focused on creating the CHAOSS Practitioner Guide series during my three years as CHAOSS Director of Data Science, and I’m proud of what we, as a community, accomplished with these guides. I’ve written quite a few blog posts about the individual guides, but I wanted to take some time here to reflect on the guides and talk about how they can be used together as a cohesive whole. The guides roughly break into two categories, which I’ll address in a series of four blog posts. The first category focuses on health and sustainability of open source projects. This post is about the first category, ‘Building Healthy and Sustainable Open Source Projects’, with part 2 coming next week to cover ‘Additional Sustainability Topics From the CHAOSS Practitioner Guides’. The second category of guides are the more advanced ones dealing with complex topics, like value, viability, and impact, that span multiple projects. Part 3 in the series focuses on value and viability while part 4 will cover determining impact.

Overview

We launched the Practitioner Guide series with a few getting started topics that apply to almost every open source project: contributor sustainability, responsiveness, and organizational participation.

The guides are paired with as ‘Introduction – Things to Think about When Interpreting Metrics’ as a starting guide with more details about how to interpret metrics in light of your unique situation. The introduction has general suggestions about how you should spend time understanding the goals of the project and talking to the people working within the project as key inputs into interpreting metrics. When it comes time to look at the metrics, focusing on trends over time for just a few metrics can help cut through the noise before drilling down into the details where there might be a potential issue. This is why each getting started guide focuses on just a few metrics to get started with tips for expanding to additional metrics as needed.

Every project is a little different, so it’s essential to interpret the metrics in light of a project’s individual needs and ways of operating. It’s also important to remember that metrics are more than just data, they represent actual human beings, so it’s important to be careful about comparing people against each other in ways that might result in the punishment of individuals. The non-human data (e.g., bots, automation, AI) should also be carefully taken into account in your interpretation of metrics. The Introduction – Things to Think about When Interpreting Metrics guide has more details about how to think about metrics and use what you’ve learned productively and ethically.

Contributor Sustainability

The Practitioner Guide: Getting Started with Contributor Sustainability focuses not just on determining whether you have enough contributors to sustain a project over the long-term, it also has tips for increasing contributor sustainability while keeping in mind that new contributors can also create additional burdens on the time of already overloaded maintainers. The guide includes Contributor Absence Factor, Contributors, and Types of Contributions as the key metrics to start investigating contributor sustainability.

To improve contributor sustainability, here are just a few of the recommendations from the guide:

  • Start by looking at your existing contributor base to determine whether you have people who are ready to step into a maintainer role, even if they start by maintaining just a sub-project. If there are people who are almost ready, some mentoring or reviewer roles might be a good first step. 
  • Before starting to recruit new contributors, it might help to review and update existing contributor guides and other onboarding documentation to help people get up to speed quickly while requiring less help from existing maintainers.  
  • Good first issues and help wanted labels can help new contributors get started on something productive, especially if those issues are created with the information that a new contributor needs to know to accomplish the task.
  • Be proactive about asking people for help with specific tasks. Knowing that we’re wanted and appreciated makes us feel good, which can be a strong motivator to contribute to an open source project or to continue contributing.
  • Defining the roles and responsibilities for contributors, reviewers, and maintainers as a contributor ladder where contributors can climb up to become reviewers and those reviewers can become maintainers can help with recruiting new people into these roles. 
  • Think about how people can move into leadership positions to be responsible for documentation, community management, marketing and other important roles.

Responsiveness

Responsiveness is one of the most important factors in attracting newcomers and retaining existing contributors for a project. The Practitioner Guide: Getting Started with Responsiveness uses Time to First Response, Time to Close, and Change Request Closure Ratio as the key metrics to help determine whether a project is responding to requests in a timely manner. It can be tempting to attempt to solve issues with responsiveness by putting more pressure on existing maintainers by asking them to respond more quickly and resolve more contributions, but this rarely solves the long-term problem. It might result in short-term gains, but it could be damaging to the community and the project over time if you are burning out your maintainers by not resolving the underlying problems that are causing the lack of responsiveness in the first place.

Some suggestions for improving responsiveness from the guide include:

  • As suggested in the contributor sustainability guide, start by looking at whether you can promote some existing contributors into reviewer or maintainer roles.
  • Use the project’s contributing documentation to set expectations about when to expect a response to a contribution.
  • Use issue and change request templates to help contributors make good contributions that require less work from maintainers.
  • Talk to your maintainers and find out where they are spending too much of their time and focus documentation or recruitment in those targeted areas.

Note that responsiveness is hard to diagnose because many things can impact responsiveness, so don’t be discouraged if your first attempt doesn’t result in improvement.

Organizational Participation

Organizations can have a significant impact on the health and sustainability of an open source project. On the one hand, organizations can help sustain projects over time by employing people to work on projects, but they also introduce risk (e.g., from relicensing, strategy shifts, acquisitions) when one organization is too dominant. From a contribution standpoint, it can be difficult if one organization has all of the influence and other people don’t feel like they are participating as equals.

The Practitioner Guide: Getting Started with Organizational Participation uses three primary metrics, Organizational Influence, Organizational Diversity, and Elephant Factor, to understand organizational participation. 

The recommendations for improving organizational participation depend on whether the improvement is coming from the dominant organization. From the dominant organization:

  • Contribution documents should be clear about whether contributions are accepted from people outside of the organization and whether those people can move into leadership positions. Transparency and setting expectations can reduce frustration from other contributors.
  • Spend some time thinking about why the project isn’t getting contributions from other organizations. Is all of the work happening in the open, and can others easily find decisions and discussions in public channels? If not, some work might be required to redirect private conversations into the public channels.
  • Promote opportunities to contribute via social media, conferences, and other channels.
  • Use your existing connections to other organizations who are using the project to encourage specific people to contribute.

From outside of the dominant organization: 

  • Engage in the project to determine whether contributions are really welcome.
  • If so, encourage your employees to contribute to the project as part of their time at work. Don’t expect employees to contribute to work projects in their free time.

Being transparent is critical. Saying one thing in the documentation and doing another can damage your organization’s reputation more than just being honest and transparent about how people can (or cannot) contribute to a project. If you are considering using an open source project as a key component of your organization’s products or infrastructure, you should think very carefully about that decision when that project is controlled by a single organization.

Summary

Increasing contributor sustainability, improving responsiveness, and garnering participation from a variety of organizations can all help improve the health and sustainability for an open source project. Check back next week for the second blog post in this series about security, diverse leadership, and sunsetting an open source project.

As always, if you want feedback or help with open source strategy, sustainability, governance, or related open source topics, I’m available for consulting engagements.

Additional Resources:

As with everything I write, this was written by a human without the use of LLMs or other AI assistance.

General

Launching the Software Stewardship Lab

I’m excited to be a part of the new Software Stewardship Lab, which is launching today! The Software Stewardship Lab is a new organization dedicated to funding research on open source sustainability, a topic very near and dear to me that I’ve been focused on for the past few years. The entire technology ecosystem relies on open source infrastructure, and there are some great organizations funding maintainers and projects, but at the Software Stewardship Lab, we’re focused on funding the research that helps us all answer questions about important topics like analysis of critical dependencies and packages analysis, which ones are / are not well-maintained, and how the maintainers of those open source projects are handling the load while avoiding burnout. 

I’m part of the team shepherding this effort. Many of the others are people that I’ve been following and have a deep respect for the work that they have been doing, so I am looking forward to continuing to learn from all of them! The team includes: Our Executive Director Vlad-Stefan Harbuz (Open Source Pledge / Open Source Endowment), Andrew Nesbitt (ecosyste.ms), Miranda Heath (report on burnout in Open Source), Daniel Roe, (Nuxt / npmx), Matias Capeletto aka patak (npmx), Mike McQuaid (Homebrew), and myself.

But we can’t do this alone. We’re looking for organizations to fund the important research that we’re doing at the Software Stewardship Lab, so that people can get paid for focusing on research around software supply chain security and maintainer burnout. Please have a look at our sponsorship page for more details about how you can help support this critical work.

You can learn more about the lab by reading our announcement post and exploring our website.

I mentioned earlier that open source sustainability is a deeply important topic for me. I think it’s important for maintainers to have the funding and other resources that they need to build projects that can become sustainable over the long haul. I’ve written many articles related to open source project sustainability, so I won’t say more now, but will instead point you to a few previous posts from my blog:

If you want feedback or help with open source strategy, sustainability, governance, or related open source topics, I’m available for consulting engagements.

As with everything I write, this was written by a human without the use of LLMs or other AI assistance.

General

From Active To Archive: Shepherding Repositories Through Their Sunset

I’ve blogged before about how not every open source software project can or should live on forever: priorities change, technologies evolve, and interests shift over time. You don’t want to have neglected or abandoned open source projects with security vulnerabilities owned by your organization. However, responsibly sunsetting an open source project is more than just clicking the archive button on your repository. This was the premise behind the CHAOSS Practitioner Guide: Getting Started with Sunsetting an Open Source Project.

The Open Source Program Office at the Digital Service at the Centers for Medicare and Medicaid Services in the US Government built on the CHAOSS sunsetting practitioner guide, contributed their improvements back into the guide, and built tooling to automate some of the tasks! They’ve done some excellent work, so I was thrilled when they asked me to join them to talk more about all of this at the recent Open Source Summit North America! The slides and video are available if you want to have a look at what we discussed.

Additional Reading:

General

Thoughts on Governance

Having good open source project governance allows us all to collaborate and work together to build more sustainable, healthy and successful projects. It’s something I’m particularly passionate about, and I’ve frequently written about it here on this blog. I collected all of those links in this post: Good Governance for Open Source Projects. Writing those posts made me realize that I hadn’t given a full presentation about governance in a while, so I was excited to have the opportunity to speak about Proactive Governance to Build Sustainable Open Source Projects at the Linux Foundation Open Source Summit NA in Minneapolis in May 2026. The slides and video for that talk are now available.

While I spend more time talking about open source project governance, I’ve also started thinking more about public governance and how open source can be a key part of a digital sovereignty strategy. But the open source impact on public governance goes beyond just digital sovereignty, which is why I was so excited to be invited by OpenGov Africa to talk more about the intersection between open source and public governance last week. The slides and video for that talk are also online.

Related Resources:


Image by the CNCF (CC BY-NC 2.0)

General

How OSPOs can Measure the Impact of OSS Funding

So much of the critical infrastructure that we all rely on contains open source projects that are under-resourced and struggling. One (of many) ways to help these projects is by funding development and maintenance so that contributors can focus on this work, but times are tough. Organizations and OSPOs are feeling the pinch, and it can be hard to justify continuing to fund open source projects. Measuring the impact of open source funding is something that I’m passionate about because the best way to continue to get leadership to give you money to fund open source is by showing them the impact of that funding. 

However, measuring the impact of funding isn’t easy, and there is no one approach, since the goals and objectives for funding vary widely for different types of funding organizations and different open source projects. It’s also important to consider that not all funding provides positive outcomes, since money can introduce tension within projects. In 2024 to help organizations navigate these challenges, I collaborated with several people to write an academic paper on this topic: A Toolkit for Measuring the Impacts of Public Funding on Open Source Software Development. We recently turned this paper into the CHAOSS Practitioner Guide: Funding Impact Measurement, which is much shorter and focused on practical steps that organizations can take to justify the impact of funding provided to open source projects and maintainers. 

The guide talks about the challenges of funding and the lessons we’ve learned along the way in addition to a section to help you navigate the actions that you can take to measure the impact. The “How to Take Action” section of the guide has three sections. 

  • First, start by understanding the context. This includes understanding the funding objectives and how the funding is structured for the projects being funded, considering project life stages and social structures, and accounting for salary structures and cost factors for different types of contributors across multiple regions.
  • Second, look at economic, social, and technological impacts across multiple dimensions. The potential social, economic, and technological impacts can be both positive and negative, direct and indirect, internal (i.e. within a project) and external (i.e. ecosystem), and manifest over different time horizons. The guide contains examples of how to think about each of these areas.
  • Third, using various methods to combine scalable quantitative measures along with contextual depth from qualitative data to better understand the funding impact. Mixed-methods approaches offer the best of both words: scalability and contextual depth. The guide and the paper have more details about how to do this.

This post doesn’t tell you how to justify getting new funding for open source efforts, so if you want to start funding open source projects, you need to demonstrate the value of that work to your leadership. There is a Demonstrating Organizational Value practitioner guide, and I’ve talked about demonstrating organizational value in several posts on this blog, which are linked in the “Related Resources” section below to provide a starting point. However, even if you haven’t yet started funding projects, you can still put together a plan for how you’ll measure the impact of that funding as part of demonstrating the value and making a case to your leadership along with the funding request.

I’ll conclude with a short quote from the guide:

“Funders need to be able to understand the impacts of past funding in order to secure buy-in for future funding as well as to adapting and/or innovating funding approaches whilst mitigating ineffective or even harmful approaches. We all benefit from more public institutions, philanthropic organizations, and companies giving money to open source; when done in a way that positive impact is the ultimate goal and objective. We hope that this guide helps organizations measure the impact of their funding initiatives so that we can increase the funding to open source projects to drive future improvements and allow these projects, and the people working on them, to become healthier and more sustainable over time.”

If you want help with measuring the impact of your funding or with other OSPO strategy topics, I’m available for consulting engagements.

Related Resources:

General

Digital Sovereignty Runs on Open Source

The tagline for Open Forum Europe’s (OFE) EU Open Source Policy Summit on January 30th in Brussels was “Digital Sovereignty Runs on Open Source,” which is in sharp contrast to last year’s tagline, “What can open source do for Europe?” At the 2025 summit, the conversations were about convincing those working in the public sector that open source was a good idea. Given the changes in the political landscape over the past year, many of those public sector folks seem to have shifted toward talking about what it will take to use open source as a key component in the EU’s digital sovereignty strategy. While we still have a lot of work to do, it feels like the conversations are moving in the right direction from why to use open source to how open source can increase digital sovereignty.

In my post last week about Funding Open Source Sustainability at CHAOSScon and FOSDEM, I talked about how open source sustainability was top of mind for me during these events considering the increase in maintainer burnout due to a lack of resources for open source projects. What struck me about the OFE event was how many people were talking about how we need to provide more resources for open source projects if the EU wants to rely on them to facilitate digital sovereignty.

In Dirk Schrödter’s keynote, he talked about how the EU doesn’t want to be locked into big US tech firms that deliver technology as black box, proprietary solutions. He mentioned that open source provides shared knowledge and skill development that leads to open innovation and lower barriers to entry, which is a key to economic prosperity. Dirk went on to say that sustaining open source software requires shifting spending to prioritize open source solutions, and public money should be spent on open source solutions. These ideas were common threads throughout the day that came up again and again in other panels and talks.

Here are a few other key points summarized from throughout the day:

  • I heard several people say that we should “never waste a good crisis,” and the current political landscape is an opportunity to re-evaluate how the EU uses technology, but speeches aren’t enough. Many public procurement policies make it difficult to use open source, and that needs to change. Procurement policies need to focus on open source to facilitate standardization and interoperability.
  • Digital sovereignty is about choice and the need to be able to switch between solutions to avoid lock in and create a transparent ecosystem to build solutions on top of open source. The EU should define concrete steps to replace proprietary solutions and transition to open source and use this as a window of opportunity to leverage what already exists, rather than reinventing. 
  • Open source is worldwide, so there is a need to fund the maintainers and people who are contributing the code wherever they are located. Open source has always been global and there is a hope that we can continue to collaborate together, rather than being isolationist. 
  • We need to all work together to strengthen and scale open source to improve sustainability, but financing and sustainability is a big challenge, and it requires investing in open source maintenance. Maintenance keeps innovation alive; it’s like plumbing, roadworks, and other infrastructure that needs to be steadily supported over time. There isn’t enough money in public budgets to make a big enough difference, so there is also a need for industry support. 
  • There is a need for action now beyond the people attending the summit. The message of using open source to facilitate digital sovereignty needs to go well beyond the tech crowd to local officials across the EU public sector.
  • OSPOs can help put digital sovereignty and open source in context and facilitate collaboration and discussions between internal stakeholders, but also between industry and the public sector. OSPOs can help organizations take a more strategic approach by contributing to and funding open source, encouraging employees to take on leadership / maintainer positions, and increasing advocacy for open source solutions.
  • There were also two announcements at the summit. First, the Open Knowledge Foundation, Open Source Initiative, and OpenForum Europe came together to launch Open Technology Research to create a sustainable global platform for research, knowledge exchange, and policy engagement around open technologies. Second, the UN published the report from the 2025 UN Open Source Week and announced that the 2026 UN Open Source Week will be held in New York from June 22 – 26.

As someone who has been working in open source for a very long time, I’ll admit to being a bit bored at last year’s event with so many discussions about why we should use open source, since I’ve been having those discussions for 25+ years. This is why I was so pleasantly surprised to see how far the conversations have evolved in just one year. The shift toward talking about what needs to happen to make using and relying on open source in the public sector along with conversations about sustainability felt like progress. There is still a very long way to go. So many open source projects are struggling with finding people, funding, and other resources to sustain themselves over time, so we need to continue to move from conversations to action so that the open source projects we all rely on will continue to thrive as even more people rely on them to facilitate digital sovereignty.

Related Resources:

If you want help with your open source strategy, I’m available for consulting engagements.

Photo from the EU Open Source Policy Summit’s photo gallery.

General

Funding Open Source Sustainability at CHAOSScon and FOSDEM

Open source sustainability impacts all of us, and unfortunately, we know that many open source projects are struggling. Maintainers are experiencing burnout, lack of funding, and a general lack of resources to sustain their projects over the long term. This is something that was top of mind for me while I was in Brussels for CHAOSScon EU, the Open Forum Europe (OFE) Summit, and FOSDEM.

At CHAOSScon, during the opening session, I talked about demonstrating the value of open source efforts with a focus on how to articulate the value within organizations so that the open source work can continue over time (slides), which is one aspect of sustainability that I’ve already talked about here on this blog. 

We also had a fishbowl panel all about funding for open source projects to wrap up the day at CHAOSScon. The funding panel covered a wide variety of topics, so here are just a few topics mentioned by the panelists:

  • Past vulnerabilities can be used to make the case for future funding (e.g., Germany’s Sovereign Tech Fund)
  • Money isn’t something that all open source maintainers want to spend time thinking about, and it can be a problem for communities to decide who gets funding?
  • We need more recognition by policy makers about the value of open source and need to revamp procurement to make it easier to use public money to fund open source. 
  • Funders need to understand the impact of their funding, but many corporate FOSS funders programs don’t have a focus on understanding and measuring impact.
  • Funding can be exploited when it’s not well-defined, and this can happen when people who aren’t particularly familiar with open source (e.g., policy, regulators, legal folks) are defining these programs.
  • Open Source Wishlist is an effort that Emma Irwin has been working on to bridge the gap between maintainers, funders, and practitioners.

I also attended several sessions in the FOSDEM Funding Devroom. Luckily, all of the devroom talks are recorded, since I wasn’t available to watch every talk, but I did pick up a few interesting tidbits from the talks that I did attend:

  • When measuring funding impact, quantitative data can help support credibility claims, but you also need qualitative data with narratives that carry meaning. 
  • Human sustainability is harder to measure than infrastructure impact, but maintainer health is a critical blind spot that should also be considered when making funding decisions.
  • Short term deliverables dominate impact measurement while long-term sustainability is undervalued because success often looks like nothing happened. 
  • Funding impact isn’t neutral. Funders’ visions shape everything: what / who gets funded, how impact is measured, and how work is valued. Funding from companies can bias development toward corporate interests. 
  • Funders often use a trust model where they fund people, projects, and organizations they trust, but that’s fragile because it’s personal, and people change roles. This is also hard to scale and creates bottlenecks. 
  • Funders often struggle to provide funding to individuals, since it’s often easier to fund projects or organizations.
  • Funding can be a time consuming and ongoing process for maintainers and projects to continue to find more funding when one wave of funding ends. 
  • It can also be hard for funders to work together to align processes and goals to create joint funding efforts.

Seeing more people talking about funding was great, and I really appreciated the thoughtful approach from several of the speakers about how funding isn’t a panacea. Funding doesn’t solve all of our sustainability issues, but it is one important tool that can help projects improve sustainability. If you are interested in learning more, we have a CHAOSS Funding Impact Measurement Working Group that meets every other Wednesday, and I am also available for consulting on this topic.

Related Resources:

Photo by micheile henderson on Unsplash

General

SCALE 23X: Corporate Impacts on OSS Sustainability

I’m thrilled to be going back to SCALE this year to talk about corporate impacts on open source sustainability!

I’ve blogged here before about the New Power Dynamics in Open Source: Rug Pulls, Relicensing, and Forks along with What your OSPO can do about power dynamics, rug pulls, and other corporate impacts on OSS sustainability, so my talk at SCALE will be an evolution of those ideas.

Here’s a quick video about why I love SCALE and a preview of my presentation topic.

I hope to see some of you at SCALE in Pasadena!

Additional Reading:

General

Good Governance for Open Source Projects

We all want our open source projects to be sustainable, healthy, and successful, and having good governance influences project success more than many people realize. I’ve had governance discussions with so many open source projects over the years. When I was co-chair of the CNCF Contributor Strategy Technical Advisory Group (TAG) we did governance  reviews and provided feedback for CNCF projects, and when I worked at VMware, Intel, and other companies, this was a regular topic that I discussed with employees who were leading and contributing to open source projects.

Last summer, I did a series of five blog posts on the topic of governance, so I think it’s time to revisit those posts. Here is a quick summary of each topic with a link to the post where you can learn more.

Governance Part 1: Why is it important?

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. 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. Being proactive about governance and related topics before something escalates into a crisis can make your projects more sustainable and reliable. 

Governance Part 2: 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. The maintainer council governance model is a simple one that many projects can use as a starting point. 

Governance Part 3: New Contributors and Pathways to Leadership

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. 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.

Governance Part 4: Creating Intentional Culture

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. 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. 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.

Governance Part 5: Overall Ownership of a Project

While there are a few exceptions, open source projects usually have an individual, company, or foundation controlling the trademarks, project infrastructure, and other assets. This overall ownership structure often impacts how the project is governed on a day to day basis and how the project is perceived by others. Neutral foundations provide a level playing field where contributors can contribute as equals regardless of whether they are contributing on behalf of a company or as an individual. This structure allows companies to collaborate together in a neutral environment where no single company is in control of the project.

I hope you enjoyed this short summary, and if you want feedback or help with governance or related OSPO topics, I’m available for consulting engagements.

Additional Resources: