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

CURIOSS: Demonstrating Open Source Value

The lovely folks from CURIOSS (Community for University and Research Institution OSPOs) invited me to join them in March as part of their Deep Dive series of talks. I gave a quick overview of CHAOSS before diving into one of my favorite topics: demonstrating the value of open source efforts. This is the first time I’ve given this talk with some additional content about how to demonstrate value in a university / academic context, which is a bit different from how we think about value in corporate environments.

The slides and video are available for you to enjoy!

Related resources:

General

Transitions

TL;DR version: As planned, my time as the CHAOSS Director of Data Science has come to an end, but I’ll still be around the CHAOSS community as a board member and Working Group (WG) lead. I’ll be taking April and most of May off before transitioning into open source strategy consulting starting in June.

The CHAOSS Director of Data Science role was funded by an Alfred P. Sloan Foundation grant for 3 years, so the plan was always to move on to something else when it ended in March 2026. I’m very proud of what we’ve accomplished in 3 years, so a huge thank you to the folks at the Sloan Foundation for the funding that allowed me to focus on this over the past few years. When I started this work, one of the first steps was to create the CHAOSS Data Science WG, which has allowed us to grow the data science community. We started the Practitioner Guide series within the WG and have published almost a dozen guides on a wide variety of topics! We also launched several research projects in addition to the Relicensing and Forks project that I’ve been focused on over the past few years. You can learn more about what we’ve accomplished by reading our updates from January 2025, June 2025, and November 2025. I feel confident that the CHAOSS data science community and the WG are in good hands as I step down and leave the work in the very capable hands of the other 2 co-chairs, Cali Dolfi and Sal Kimmich, and maintainer, Ernest Owojori.

However, I’m not leaving the CHAOSS community. I’ll still be on the CHAOSS Governing Board and will continue co-chairing the OSPO WG, Funding Impact Measurement WG, and the Education WG. All of these WGs have co-chairs, so WG meetings will continue and nothing should change while I’m enjoying some time off to rest and recharge in April and May. The only exception to my time off is to attend the Open Source Summit in Minneapolis in May, since I didn’t want to miss it. I’m disappointed to need to say this, but I also wanted to make sure people know that this transition and the time off has been planned for over a year and has nothing to do with the current drama unfolding in the CHAOSS project this week.

What’s next? While I’ve enjoyed being able to focus on data and metrics over the past few years, I’ve found that I missed working on open source strategy, which has been my focus over the past two decades. The data science work was a fun diversion, but now I’m ready to get back to my roots. Starting in June, I’ll be shifting into open source strategy consulting. This is NOT a temporary solution while I figure out what to do next. My plan is to continue consulting on a part-time basis while I free up some time for my other hobbies (reading, working out / running, designing 3D prints, traveling), and to continue to do this for as long as I remain able to work. 

You can learn more about my consulting business on my consulting website, but here are a few focus areas:

  • Open Source Strategy: Crafting strategies for your OSPO, open source teams, or product teams that help employees focus their open source work in areas with the most impact along with demonstrating the value of your open source efforts to your executive team.
  • Contributor and Community Strategy: Strategies and techniques for growing your contributor base and improving sustainability for the open source projects driven by your organization and when working upstream.
  • Governance: Documenting and improving project governance processes for open source projects along with providing advice when there are governance issues or concerns.
  • Research and Data Analysis: Open to a variety of research and data projects to answer questions you have about open source projects from understanding an existing contributor base to doing audits of your GitHub organizations to understand the status of your repositories.

If you’d like my help in any of these areas, please reach out to me in June!

General

Reflections from FOSS Backstage 2026

FOSS Backstage is one of my favorite conferences, and again this year, I had an amazing experience. I saw interesting talks, caught up with friends, met new people, and still missed talking to a few people!

As with most conferences in Europe, digital sovereignty was a hot topic with quite a few talks touching on various aspects of the topic. Mirko Boehm talked about the role that open source can play in digital sovereignty, but it’s not quite so simple, since it requires participation in addition to adoption. Nicholas Gates gave a nice overview of the OSOR Report on Open Source in European Local Governments. Jan Lehnardt talked about the Sovereign Tech Agency’s Bug Bounty program. Andy Piper introduced how Digital Public Goods (DPGs), like Mastodon, can be part of a digital sovereignty strategy. Jutta Kreyss had a very interesting talk about how the city of Munich has approached measuring digital sovereignty. Dr. Daniel Gerber talked about how a FOSS foundation is working with the state of Saxony in Germany.

Slide with 3 poodles in little red and black striped ties with white collars. Text reads: The CRA (canine responsibility act) as it applies to poodles. Nesbitt, Nesbitt, and Nesbitt Attorney-at-Paw. Andrew Nesbitt and Ben Nickolls standing on either side of the podium at FOSS Backstage 2026.

There were also many other interesting talks on other topics. Æva Black used an interesting story telling approach to cover some historical inflection points and what we can learn from them to improve the security of open source as we learn how to comply with the Cyber Resilience Act. Dr. Wolfgang Gehring shared some of what they’ve learned running an inner source program at Mercedes-Benz. Benjamin Nickolls and Andrew Nesbitt talked about how they dove into some ecosyste.ms data in an attempt to answer the question, “Is the InnerSource Commons good for open source?”, which they asked during a talk at last year’s FOSS Backstage event. Max Mehl and Cornelius Schumacher focused on the supply chain but by looking at how to balance risk, value, and people with the OSPO sitting at the intersection of all three. I also moderated a panel with Peculiar C. Umeh, Ruth Ikegah, and Stephen Walli to talk about educating the next generation of open source contributors.

These are just a few of the talks that I attended, and I heard that some of the talks I missed were also great! Videos of most or of the talks should be available soon, so I encourage you to have a look when they are published!

Related Resources:

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

Keynote image of Æva Black by the FOSS Backstage photographer. 

General

Power Dynamics, Rug Pulls, and Other Corporate Impacts on OSS Sustainability at SCALE 2026

As many of you know, this isn’t a new topic for me. I’ve written here about what your OSPO can do about power dynamics, rug pulls, and other corporate impacts on OSS sustainability along with a post on the OpenUK blog, The Shifting Power Dynamics in Open Source: Rug Pulls, Relicensing and Forks, and on The New Stack, Clouds, Code, and Control: The New Open Source Power Struggle. I’ve also given other presentations on this topic, so you can watch the video from the recent Open Source Summit EU (OSSEU) in Amsterdam, which Jon Corbett did a lovely job of summarizing in his LWN Coverage of the talk. 

I’ve been continuing to think about how power dynamics and rug pulls impact OSS sustainability, and I had an opportunity to talk about this at SCALE 2026 in Pasadena last weekend! I already blogged about how much I love SCALE, so I won’t continue to gush about how great it is. SCALE gave me a bit more time than I’ve had for the other presentations, so I added some new slides about other types of rug pulls beyond the relicensing and forks that I’ve previously focused on. I talked more about MongoDB, which kicked off the recent wave of relicensing when they relicensed under the newly created Server Side Public License (SSPL), which didn’t result in a fork. I also talked about some examples of rug pulls that came about when images / releases were put behind a paywall (Bitnami / Linkerd). My slides are a bit sparse, but available, and SCALE will also release the video of the talk if you want more details.

Resources:

I’m available for consulting engagements focused on open source strategy, contributor strategy, improving project governance, and related topics.

General

Podcast: What Does a Healthy OSPO Actually Look Like?

I’ve been spending quite a bit of time recently reflecting on how Open Source Program Offices (OSPOs) and our work in open source is evolving in a world where most of us don’t have as many resources as we need to support our open source work while at the same time, we’re experiencing an increasing reliance on open source as a key strategy for digital sovereignty. I started doing open source strategy work back in the very early 2000s at Intel, and in the 5 years before CHAOSS, I was in open source strategy roles at Pivotal and later VMware, so I’m looking forward to spending more time working with OSPOs as a consultant. 

My recent conversation with Rachel on the Contribute: Beyond the Code podcast was a great excuse to reflect on some of what I’ve been thinking and writing about related to OSPOs. You can watch the full episode on YouTube, Apple, or Spotify.

We talked about how OSPOs can:

  • demonstrate the value of open source work within an organization.
  • have a bigger impact in open source when they go beyond compliance 
  • scale their efforts through documentation
  • balance internal enablement along with external engagement
  • track the most strategic open source projects for your organization
  • responsibly sunset (archive) open source projects
  • develop processes that make it easy for employees to engage in open source

Additional Reading:

General

Open Source Software: A Path to Building Leadership Skills

In traditional top-down employment structures, if a manager asks an employee to do something, there is an expectation that they will do what was asked. In the manager / employee relationship, the manager has quite a bit of power over their employees. The really great managers collaborate with their employees and lead with empathy, while less experienced and less competent managers rely on power dynamics to get employees to complete their work. In contrast, leadership in open source requires influence without power, which can help build skills in leading through collaboration, influence, and empathy to help people become truly great managers and leaders. I’ve been managing people within companies for 20+ years, and I’ve learned so much about how to be a better leader and manager through my work in open source.

A common pattern in open source is that a community member finds something to contribute and then contributes it, regardless of whether they are doing this as an individual or on behalf of a company. Those contributions are often followed by an interactive feedback process. A maintainer might review the contribution and request some changes, and the contributor will usually need to make some modifications before the contribution is accepted. In this case, the maintainer needs to be able to clearly communicate the request for modifications and use their influence (not power) to convince the contributor to keep working on the contribution until it can be completed. The contributor needs to collaborate with the maintainer and maybe even negotiate a solution that works for both of them. They both need to collaborate and use influence and collaboration, rather than power to find the best solution.

Another common pattern in open source is that there are activities that need to be accomplished, but the people involved in that part of the project don’t have the time or the skills to complete those activities, or they want to use those activities as a way to encourage newer contributors to get more involved. In this case, the people who want the work done will need to reach out to the community or to individuals and encourage others to contribute. This usually means convincing potential contributors of the value of these activities and using influence and negotiation skills to help people complete this work. Again, these are valuable managerial and leadership skills that can be learned and practiced by participating in open source projects. 

These skills can be developed even if you aren’t in a formal leadership position within a project. If you are a regular contributor, there is probably something you’re working on where you could use help from others. By getting others to help with this work, you can practice your leadership skills. I also encourage people to volunteer for leadership positions. There might be existing positions that need a leader, but you can also volunteer to lead something even when that leadership position doesn’t currently exist. You can volunteer to lead a user group, facilitate a meeting, start a podcast, manage a project, or anything else you can think of that might need doing. For those of you working within OSPOs, you can encourage your employees to think about using their work in open source projects to help build leadership skills, in addition to just considering open source work as a way for someone to gain new technical skills.

I know that some maintainers don’t like to think of themselves as managers or leaders, but a lot of maintainer responsibilities are more managerial than just writing code, and they require leadership skills. Even if you don’t aspire to become a people manager as a career, the leadership skills learned in open source projects can improve your interactions with other people both personally and professionally.

Additional Resources:

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

Photo by Brooke Lark on Unsplash

General

OSPO Contribution Strategies to Demonstrate Value

Many OSPOs struggle to demonstrate the value of their organization’s contributions to open source projects. A good way to demonstrate the value of these open source contributions is by showing how the work helps your organization achieve its goals, and this is an approach that I’ve used when working in several different companies.  

Every leadership team has to look across the entire organization and prioritize the efforts that have the biggest overall impact on the organization as a whole. This means that if you want your leadership to continue to staff and fund your OSPO or other open source teams, you need to make the case for why your work is as important or more important than other efforts that are also competing for limited resources. Having a clear open source strategy where you can tell the story of how the open source work helps achieve the organization’s goals is a great way for leadership to understand the importance of the work so that you can continue to do it. 

Clearly articulating the importance of your contributions to upstream projects should be an important piece of that open source strategy. This often has 2 components: 1) identifying which projects are most strategic / critical for your organization and 2) creating contribution strategies for individual projects.

Identifying Strategic Projects

When deciding where to focus your organization’s upstream contributions, I’ve seen a lot of people struggle with the difference between open source projects that are frequently used within an organization vs. the projects that are truly strategic. The way I like to think about this is by asking whether I could easily drop in a replacement. You might use a tiny library in a bunch of your products to make some task quicker and easier, but if you could easily replace it with something else, like another similar library or you could re-write it yourself pretty easily, then it’s not likely to be a strategic project that is critical to your organization. Something like Kubernetes on the other hand is an incredibly complex piece of software that could not be easily replaced, and if you’re relying on it to be able to deliver products and services to your customers, then this would probably be a strategic project for you. You’re unlikely to get much value out of contributing to that tiny library, but you might get value out of contributing to those more strategic projects. 

When I was at VMware, I was responsible for maintaining our list of strategic projects. This came about because executives would ask which open source projects were most important to us, and before creating the strategic projects list, all we had to give them was the list of packages that appeared most frequently in our products, but this wasn’t what leadership wanted. They wanted to know which open source projects were most critical or most strategic for us. We started creating a list of strategic projects by talking to the product leads in our business units to ask them what open source projects they relied on and couldn’t deliver products to our customers without those projects. It provided a window for executives into what projects were most important and most strategic while also helping our business units coordinate with each other when they were engaging in the same projects. 

Contributions Strategies for Individual Projects

This strategic projects list also provided a start toward justifying having people contributing to those projects, but it can help to dive into the details of some of these projects to look at project health, feature maturity, and other aspects of each project to decide where you might need to contribute. For example, when I worked at Pivotal, I was responsible for our open source strategy, and Kubernetes was a big part of that strategy. This was before the VMware acquisition of Pivotal, and we were in the process of making the shift from using Cloud Foundry as the base for our main products to using Kubernetes. This was a huge shift for the company. Pivotal was one of the creators of Cloud Foundry and we had a ton of influence in that project, while we were just getting started with Kubernetes. I spent quite a bit of time talking to the people in leadership who were driving this shift along with the people responsible for driving the individual product strategies with a focus on where we wanted to be in a few years. I also started engaging directly within the Kubernetes community to explore the different aspects of Kubernetes while talking to our engineers about which parts of Kubernetes were missing features or lacking maturity so that we could match what we were going to need in the next few years with the areas within Kubernetes that would need work if we wanted to base our products on top of it.

I used all of this information to create a written strategy that clearly tied our open source Kubernetes work back to our overall company mission and goals, and I was able to get people allocated to upstream Kubernetes by showing how our long term product strategies relied on specific areas within the Kubernetes code base, and outlining where we needed to make contributions to support those products. We then continued to track those contributions so that we could show the value that we were providing back to the company. 

This was my approach when I was at Pivotal and later VMware, but every company and every open source project is unique, so this requires customizing your approach so it works for your organization. The CHAOSS project has an entire Practitioner Guide on the topic of Demonstrating Organizational Value with some additional ideas for how to demonstrate and frame the business value of your open source work. If you want feedback or help with your open source strategy and how to demonstrate value for your organization, I’m also available for consulting engagements.

Additional Resources:

Photo by Ian Hutchinson on Unsplash

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

Open source, research, and other stuff I'm interested in posting.