Tag Archives: practitioner guides

General

Strategic Approach to CHAOSS at OpenChain x OSPOlogy Prague

I’m excited to be leading the Roundtable Discussion at OpenChain x OSPOlogy Prague on October 6 on the topic of taking a Strategic Approach to Improving your OSPO using CHAOSS.

Hero image for Roundtable Discussion: [GROUP B] Strategic Approach to Improving your OSPO using CHAOSS. MENTOR: Dawn Foster (TODO Group Ambassador). October 6, 2026. 13:40 - 14:40. Deloitte Offices. OpenChain X OSPOlogy Prague 2026.

Metrics can provide deep insights into our open source initiatives, but they can also be overwhelming and require interpretation. Interpreting metrics and understanding what they mean is only useful if you drive appropriate actions to make decisions and improvements based on those metrics. In this roundtable, we’ll use a strategy first approach to discuss how to use metrics, tools, and practitioner guides from CHAOSS to improve the work within your OSPO whether you want to improve OSS projects themselves, assess their viability / risk for your organization, or demonstrate the value and impact of your OSPO.

Since this will be facilitated as a roundtable discussion, here are some links that participants (and anyone else) may find helpful.

Approach:

CHAOSS Practitioner Guides:

Metrics:

Tools:

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

General

Part 4: Assessing Impact Using CHAOSS Practitioner Guides

This final post in my series about using the CHAOSS Practitioner Guides focuses on determining impact for two specific cases: Funding Impact Measurement and Research Software Impact. If you haven’t already read the previous posts in the series, I encourage you to pause and read those first:

Funding Impact

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. Funders need to be able to understand the impacts of past funding in order to secure buy-in for future funding as well as 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.

The Practitioner Guide: Funding Impact Measurement has several things to consider when measuring impact:

  • Start by understanding the context. Accounting for funding objectives, project life stage and social structure, and regional and organizational cost factors is an important first step in measuring funding impact, since it provides important context.
  • Economic, social, and technological impacts can be both positive and negative, direct and indirect, internal (i.e. within a project) and external (i.e. among a project’s ecosystem of dependents and users), and manifest over various time horizons. When assessing the impacts of open source funding, there may be a tendency to focus on technological impacts, which may in part be due to the nature of open source or the relative ease of measuring data from repositories. However, the potential impacts of funding extend beyond the code itself, and it is crucial to consider economic and social impacts on projects and their wider ecosystems of dependents and users.
  • Methods. When it comes to measuring the impacts, funders can consider a breadth of methods for impact measurement. We recommend using a mixed methods approach, which provides a way to combine scalable quantitative measures along with contextual depth from qualitative data to better understand the funding impact.

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. Most of this guide came from a paper that I co-wrote with Cailean Osborne, Paul Sharratt, and  Mirko Boehm, so a big thank you to my co-authors and others from the CHAOSS Funding Impact Working Group for supporting this guide!

Research Software Impact

Looking at the impact of research software requires a very different approach from the corporate context, so we have a guide dedicated to that topic: Practitioner Guide: Research Software Impact. Software and open source community work does not have a history of being part of reappointment, tenure, and promotion cases and has not represented a traditional outcome of university research work. To make this even more complicated, there are no consistent international practices for using software identifiers or citing software. A huge thanks to Matt Germonprez and Clare Dillon for writing this one!

The guide highlights the importance of open source software and community work as significant scholarly outputs using several metrics for determining research software impact:

  • Contributor Absence Factor. For researchers and evaluators, the contributor absence factor is helpful in understanding how an open source project is growing to include contributors who are responsible for more than 50% of the code base.
  • New Contributors. A steady influx of new contributors may indicate a healthy, inviting project, while declines can be a signal for potential challenges in engagement or accessibility.
  • Project Velocity. A researcher can use the Project Velocity metric to report project velocity of their own open source project and compare project velocity across a portfolio of projects.
  • Change Requests. The Change Requests metric tracks the proposals for modifications to a project’s source code that have been submitted for review during a given time frame.
  • There are also additional metrics, like software citations and external funding, that may be used if they are available.

The guide focuses on the impact of open source software and/or communities created and maintained by individuals and teams as part of their research role, including evaluators who are part of researcher reappointment, tenure, and promotion cases. This guide focuses on open source software and communities developed and maintained by a researcher or team to recognize the social and technical impact from that work.

Summary

These are very different guides that both focus on assessing impact within slightly niche topics that only apply in specific situations. However, they would also be useful when brainstorming ways to assess impact in other situations. 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. In particular, I’m interested in working with organizations who need help assessing the impact of their open source funding initiatives.

Additional Resources:

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

General

Part 3: Determining Value and Viability Using CHAOSS Practitioner Guides

This third post in the series about using the CHAOSS Practitioner Guides is quite different from Part 1 and Part 2, which both covered the Getting Started Practitioner Guides with Part 1 focused on contributor sustainability, responsiveness, and organizational participation and Part 2 focused on security, diverse leadership, and sunsetting. All of the topics in those earlier posts are ones that are addressed on a project by project basis. If you haven’t read the previous posts, you might want to pause now and read them before continuing here.

This post is focused on two of our more advanced / expert practitioner guides that help organizations look more holistically at open source initiatives that span across projects. This post is particularly relevant for Open Source Program Offices (OSPOs), but can be used by anyone focused on open source with a variety of different types of organizations. This post covers two more complex topics with guides that are much more extensive than the getting started guides:

Demonstrating Organizational Value

Open source teams and OSPOs often experience pressure from leadership to drop and / or reduce their open source contributions to focus on internal initiatives that deliver more value to the organization. This puts open source teams in the position of needing to justify their work in open source to demonstrate that it has as much or more value than other initiatives that employees could be working on. However, it can be difficult to frame the justification in ways that resonate with leadership and clearly articulate how the organization benefits from continued contributions to an open source project. Thank you to Bob Killen for providing quite a bit of the content for this guide based on his experiences when he worked at Google.

The Practitioner Guide: Demonstrating Organizational Value has a framework for demonstrating value that includes:

  • Goals. Start by focusing on supporting your organization’s goals. The priority for investment (allocating staff or other resources) in open source can be framed as a combination of criticality and project health risk that is unique to your organization.
  • Criticality. Determine which open source projects are the most critical for your organization by looking at dependencies, opportunities to influence projects, and supportability of the projects you use.
  • Health Risk. Assess the project health risk of the open source projects that are important for your organization using a variety of metrics highlighted in the guide.
  • Priority. Prioritize within your limited resources using a combination of criticality and project health risk as determined above.
  • Value. Use all of this to measure and frame the value in ways that your leadership can see why contributions to certain projects are important to helping the organization achieve its goals.

One guide can’t possibly cover everything about demonstrating the value of your organization’s open source efforts, so this is just a fraction of the potential ways that open source investments can be tracked and tied back to goals while effectively describing the value of the contributions. It requires the right framing and ensuring that resources are allocated where they may have the most value; however, the framing and resource allocation will be different in almost every situation, since it depends on your organization’s unique needs. 

Assessing Viability

Evaluating the viability and the risk that comes with specific open source projects is important to avoid disruptions that hamper the ability for your organization to deliver products and services to customers, especially when a key dependency suddenly becomes unviable. Assessing the viability of open source projects, especially ones that have the potential to impact the business, is a good first step toward managing risk and reducing the chances of potential business disruptions. A huge thank you to Gary White for writing most of the content in this guide based on his viability assessment experiences within the Verizon OSPO. 

The Practitioner Guide: Assessing Viability walks through several categories of metrics that should be considered when assessing viability:

  • Compliance and Security assesses a project’s licensing fit, vulnerability risk, and maintenance activities. It is important for users to comply with any responsibilities they may hold to an organization or to the creators of a project.
  • Governance metrics are useful to show the intention or lack of intention in the project’s governance and help define decision-making processes. The ability to contribute, understand, or depend on a project is highly coupled to the effort behind governance.
  • Community metrics indicate how the community maintains a project and how much interest there is generally. A key aspect of viability is community activity and adoption, because without an active community, an open source project is not likely to continue to evolve and grow. The idea is that an active community surrounding a project is more likely to drive better performance, vulnerability management, and feature-completeness to ease development downstream.
  • Strategy metrics help to determine the influence that individuals and organizations have within a project. 

Organizations should be thinking strategically about project risks in light of how they are using the projects. If it’s a critical part of a technology stack, it should be as low of a risk as possible. On the other hand, if an open source project is used as a small part of some non-critical infrastructure, an organization can accept more risk. Assessing viability and thinking about it from the perspective of risk and which risks to accept is an important first step, but it’s also important to think about which risks can be mitigated to improve viability. The best way to mitigate many of these risks is by paying employees to contribute to the projects that are most important to your organization. This provides an opportunity to improve viability and sustainability, but it also provides insight into where the project is heading and how things are going, so that if something changes in the project to further increase risk, it might be easier to anticipate those changes.

Summary

Determining value and assessing viability are topics that may seem distinct, but quickly become intertwined, especially within OSPOs. When determining value, one step is to look at how important or critical the project is within your organization. Those critical or strategic projects should also get a viability assessment, which can help to determine project health, which is the other side of the value equation in the guide. Both of these guides used together can help your organization justify the value of your open source contributions both from the strategic side (organizational value) and for understanding and mitigating risks (viability). Check back next week for the final post in this series, Part 4: Assessing Impact Using CHAOSS Practitioner Guides.

As always, if you want help with either of these topics or more generally need advice or feedback on 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

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

Demonstrating Organizational Value

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! If you want feedback or help with your open source strategy and how to demonstrate value for your organization, I’m available for consulting engagements.

Related blog posts:

Photo by Farhat Altaf on Unsplash

General

Strategy Before Metrics

I’ve been involved with open source project metrics for a very long time, and people often ask me which metrics they should use, but this isn’t really a question that I can answer. What you measure and how you interpret those metrics depend on your goals and what your organization is trying to accomplish. For this blog post, I’m using “organization” loosely. It could mean your company, university, or non-profit, but it might also mean aligning with funding organizations if your OSPO or other open source efforts were funded by another organization. 

The CHAOSS Practitioner Guide: Introduction – Things to Think about When Interpreting Metrics mentions:

“one of the best places to start isn’t actually with the metrics, but by spending some time understanding the overall goals for the project. If the project is primarily driven by one organization or owned by an organization, you should also consider the goals for that organization. By thinking strategically about the overall goals, you’ll be in a better place to decide what you need to measure to determine whether the project is achieving its goals. Open source projects generate a tsunami of data that can be overwhelming, but by focusing on the goals, you can develop a metrics strategy that helps you focus on the metrics that matter most for a particular project.”

It can help to ask yourself, “what is important for my organization or the project?” This often means starting with your team’s open source strategy and aligning it with your organization’s goals. The most important part of putting together strategies and plans for your open source efforts is aligning them with the overall goals for your organization. By taking some time and effort to make sure you support the overall strategy for your organization, then it will be much easier to justify continuing these efforts during the next planning or funding cycle. This will also help you make the case to senior management, executives, funders, and others on the leadership team who aren’t likely to be involved in the low level details. Explaining how your open source contributions support the goals of your organization can help the executive or leadership team understand the strategic importance of this work so that you can continue your work in open source.

Once you have a strategy defined that aligns with the strategy of your organization, then you can figure out what you need to measure to show whether you are achieving your goals. There are a couple of reasons that starting with the goals is important, since metrics can go awry if you aren’t focused on the right things.

  • You won’t know if you are successful if you aren’t measuring the right things. If you aren’t measuring the things that are important for your project or organization, you won’t know if you are making progress in the areas that you care the most about. For example, if you want to improve the performance of a particular piece of open source software, you’ll want to have success criteria and measurement based on specific types of performance. If you want to gain influence within an open source project, maybe you measure increases in contributions or the number of employees moving into positions of influence. 
  • Measurement impacts behavior, and people do different things depending on what you measure. For example, if you publish metrics that focus on the number of comments on issues, you are likely to start getting more comments on issues. If what you are really trying to do is get people to help review and approve contributions, then additional comments on issues might not help as much as looking at reviews on change requests (pull requests / merge requests). 

Once you decide on your success criteria, you need to make sure that you can get the data required to measure it and start measuring it now to get a good baseline. There are plenty of tools available to gather contribution data about open source projects. Some of the commonly used tools can be found in the CHAOSS project, but you can also likely get a pretty good sense for the data by looking at your code repositories and other communication channels. GitHub, for example, has some pretty good data under the insights tab.

After you have your metrics, you need to actually do something with them to show that you are making progress toward accomplishing your goals. Think about which metrics you should be showing to your leadership and which ones should be shared with your team and the broader community. But communicating metrics is much more than just showing some charts or graphs, you also need to interpret those metrics and tell the story about what they mean. The CHAOSS Practitioner Guides can help you think about the interpretation and how you might tell the story about what your metrics mean. Without interpretation and explanation, all you have are numbers, which are way less powerful than the story about what the data means in the context of how it helps your organization achieve their goals. If you want feedback or help with your open source strategy and how to use metrics, I’m available for consulting engagements.

Here are a few additional links and resources to help you think about building your metrics strategy and telling the story about what the metrics mean:

Photo by Hassan Pasha on Unsplash.

General

CHAOSS Data Science Working Group

When I started in the role of Director of Data Science for CHAOSS, one of the first things I did was start the Data Science Working Group (WG) as a way to build community around the data science work that many of us were already doing within the CHAOSS project. I am incredibly proud of what we’ve accomplished in less than 2 years.

Yesterday, we published a CHAOSS blog post about what we’ve been working on lately, but here are a few highlights.

We’ve released 7 Practitioner Guides: Introduction, Contributor Sustainability, Responsiveness, Organizational Participation, Security, Building Diverse Leadership, and Sunsetting an Open Source Project. I’ve covered these in more detail in 2 recent blog posts about Using CHAOSS Practitioner Guides to Improve your OSS Projects and From Data to Action: Building Healthy and Sustainable Open Source Projects.

We are also driving several research projects out of the working group. I’ve already blogged about the Relicensing and Forks research that I’ve been working on, but we also have research looking into projects that move from private ownership into a foundation, archived projects, and a collection of research taxonomies.

You can read the CHAOSS blog post to learn more!

I also wanted to remind people that like all of the CHAOSS working groups, the Data Science WG is open to everyone! All you need to join the Data Science WG is an interest in using data to understand the open source world around us. Most of our work is analysis of data, writing guides, and discussions about using metrics. You don’t need any special skills, and you don’t need to know any advanced statistics, machine learning, or AI. We’re even planning a CHAOSS Data Science Hackathon, which will be  co-located with Open Source Summit North America and CHAOSScon in Denver, CO on June 26, 2025. To learn more, visit our repository, join our meetings, or reach out to us in the #wg-data-science channel in CHAOSS Slack. We hope you’ll join us!

General

From Data to Action: Building Healthy and Sustainable Open Source Projects

Last week, I had an article published in Computer magazine, an IEEE publication: From Data to Action: Building Healthy and Sustainable Open Source Projects (the PDF version is in an easy to read format). One of the primary ways that the CHAOSS project is helping people improve the health and sustainability of their open source projects is via the Practitioner Guide series, which I covered in more detail in the Computer article.

On a related note, we’ve published two new Practitioner Guides this week: Getting Started with Sunsetting an Open Source Project and Getting Started with Building Diverse Leadership! These new guides complement the previously released guides that I talked about in a recent blog post. The rest of this post has a few more details about the Computer magazine article and the two new guides.

In the Computer magazine article, I talked about how the CHAOSS project is providing advice and resources for proactively using metrics to improve open source project health and sustainability before a crisis occurs to make software more sustainable and reliable for everyone. Here’s a short quote from the Computer magazine article:

“Building sustainable open source projects over the long term can be a challenge. Project leaders, maintainers, and contributors are busy people who don’t always have the time to focus on growing a community along with maintaining their software. Using metrics is one way to help identify potential issues and areas where a project can be improved to make it more sustainable over the long term. Metrics are best used if they aren’t used once and never again. By monitoring the data over time, projects can understand trends that might indicate areas for improvement as well as see if those improvements are having the desired effect. Being proactive about improving sustainability before it becomes a crisis can help make open source software more sustainable and reliable for everyone” – Read the rest of the IEEE Computer magazine article for more.

The newest guide in the series, Practitioner Guide: Getting Started with Building Diverse Leadership, was written by Peculiar C. Umeh. It expands on the theme of improving health and sustainability of open source projects by creating a welcoming and inclusive environment that encourages contributions from a wide variety of people. Here’s a quote from the guide:

“A community or project with diverse leadership offers significant advantages because diverse leadership leverages diverse perspectives to build an innovative community, create a welcoming and inclusive environment, and empower individuals from all backgrounds to contribute their unique talents. New and existing contributors feel more included when they can see other people in leadership positions who are like them (Linux Foundation, 2021). When diverse leaders collaborate, their intersection sparks innovation and creates a more harmonious global leadership system. It represents a global and diverse user base, which improves the usability of the project because more users’ voices are represented in decision-making about the project’s design and functionality. It enhances decision-making processes by incorporating various viewpoints and experiences, leading to better problem-solving and more effective strategies. It promotes a culture of inclusion and respect, improving morale and engagement among community members and ultimately contributing to projects’ long-term success and sustainability.” – Read the Practitioner Guide: Getting Started with Building Diverse Leadership for more.

The other new guide in the series, Practitioner Guide: Getting Started with Sunsetting an Open Source Project, is also about making open source more sustainable by being clear about the future of an open source project so that users can make responsible decisions and avoid using open source technologies that are no longer being maintained or updated with security fixes. Here’s a quote from the guide:

“Many open source projects, even widely used ones, become abandoned for a variety of reasons (e.g., evolving interests, family situations, employment changes), but abandonment can be done in a responsible way by proactively sunsetting the project (Miller et al. 2025). Sunsetting is an important consideration for corporate environments where it can be easy to lose track of projects that were created by employees who later walked away from the project and left if abandoned. You don’t want abandoned open source projects with security vulnerabilities sitting in your organization’s source code repositories where someone might trust that project simply because they trust your organization. Finding inactive projects and responsibly sunsetting them is a good business decision and something that many open source teams / Open Source Program Offices (OSPOs) do on a regular basis. 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. Sunsetting an open source project should take your user’s needs into account, and where possible, offer users time to migrate to a replacement technology. At a minimum, it’s important to signal that the project will no longer be maintained, updated, or have security patches so that users know that they should no longer be using the project.” – Read the Practitioner Guide: Getting Started with Sunsetting an Open Source Project for more.

As always, these CHAOSS guides are under an open source license, so you’re free to use and modify them to meet your needs.

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

Photo by Jennifer Delmarre on Unsplash.