General

How OSPOs Can Take a More Strategic Approach to Conference Talks

Dawn giving a keynote at KubeCon EU wearing all black with a VMware t-shirt and purple hair in front of colorful background.

A lot of the work that we do in open source projects is based on the relationships we have with other people. By having key employees attend conferences focused on their open source work, those employees can build deeper lasting relationships with others that will benefit your organization and your employees. These existing relationships make it easier to collaborate with others, and it’s sometimes easier to work through really difficult, big issues when you have a group of people together at a conference. It’s also easier to communicate with someone later online if you’ve met them in person. I have deep and lasting connections with people that I’ve met at events, which often allows me to make introductions to help a colleague learn something new or solve some tricky issue. Conference talks also showcase the work that employees are doing within your organization both for potential customers and when recruiting new employees either now or in the future. 

However, getting talks accepted at important conferences doesn’t always just happen organically, and this is where your Open Source Program Office (OSPO) can play a strategic role in getting the right people speaking at the right conferences. I’ve seen too many examples where no employees get talks accepted at conferences that are important for the organization, and other times where you have one individual spending too much time at conferences while other people aren’t getting the same opportunities to attend. By getting organized and taking a strategic approach to conferences, your OSPO can help to get your employees speaking at the conferences with the biggest benefit, both for those individuals and for the organization as a whole.

I ran a process for doing this when I worked at Puppet, and it helped us get more talks accepted at the conferences where we wanted to have a presence. This was accomplished with input from product teams, engineering, marketing, events, and other key stakeholders. Here are the steps you can use to replicate that process:

  1. Select strategic conferences based on which conferences are most important for your organization.
  2. Identify topics and speakers for each conference in areas that are important to the organization and with speakers who would benefit from attending that specific conference. Imposter syndrome can play a role in this step with some people thinking that only the world’s leading expert can give a talk, so it might take some encouragement to help them understand that they just need to know some things that a person new to the topic would need to know. I have an entire video about imposter syndrome for giving conference talks.
  3. Create timelines and reminders to make sure that talk proposals are prepared in time for your review process and then to meet conference deadlines. I’ll admit that this part of the process required a fair bit of following up and reminding people about the deadlines.
  4. Review and provide feedback on proposals to help employees craft talk proposals (along with appropriate bios) that are more likely to be accepted. Writing excellent proposals requires some specialized skills, so you should recruit a few people who have sat on program committees to help with these reviews. This review process should also be open to anyone who wants to submit a talk, not just the people you’ve identified, because there will be additional topics and conferences that are important for some individuals that you didn’t anticipate.

If you don’t feel like you can run this full process right now, at a minimum, encourage submissions to your most important conference and get people to review those proposals. We did this one year when I worked at Pivotal by encouraging people to post their KubeCon talk proposals into a Slack channel where several of us with talk selection experience reviewed those proposals, and we went from having almost no talks at KubeCon to having about a dozen talks across a wide variety of topics. A lot of people are terrible at writing talk proposals, and a little bit of direction from someone with the right expertise can make the difference between acceptance and rejection.

However, there are a few gotchas to watch out for that are likely to get a talk rejected, regardless of the topic:

  • The person speaking needs to submit the talk proposal. Never submit a talk on behalf of someone else, since for many events, this is an automatic rejection, even when they give you the option to do it.
  • Do not submit anything that looks even slightly like a product pitch. Audiences don’t like to be pitched to, so conferences decline these for a reason.
  • The bio is as important as the talk abstract, and it should be written to highlight why the speaker is the right person for this particular talk. It should not be something generic that is thrown together as an afterthought.

I hope this helps your OSPO get the right people giving talks at the conferences that are the most important for your employees and your organization!

Additional Resources:

General

Governance Part 5: Overall Ownership of a Project

A bunch people's arms with hands in the center with sleeves of various colors..

This is the fifth blog post in a series about open source project governance, so while this one can be read on its own, you might still consider pausing and reading about why governance is important, defining governance, pathways to leadership, and creating intentional culture.

People sometimes think of open source project ownership as something a bit nebulous with projects owned by an undefined “community” of people; however, this is rarely the case from a legal standpoint. 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. 

For projects owned by individuals, there are often concerns about succession planning and the impact on the project if something happened to that individual (see obligatory xkcd dependency comic about the one maintainer in Nebraska). This can result in concerns about the sustainability and risks associated with using projects owned by single individuals.

For company owned open source projects, if the project is truly open, the governance processes should specify how people can move into leadership positions with the assumption that you’ll eventually have maintainers from outside of your company. On the flip side, if you have no intention of allowing people from outside of your company to move into leadership positions or make decisions, then you should be clear about that and keep the project as owned by your company. While it’s not ideal, I have a lot more respect for companies who are honest about how others can participate than ones that claim to be open while still making all of the big decisions behind the closed doors of their company.

On the other hand, we have foundations for open source projects, which tend to be non-profit organizations that are focused on providing the resources and organizational structures that projects need to get funding and legal support for their work. In many cases, projects end up in foundations because an individual or company decided to move the project into a foundation. 

It’s also important to think about when your project might be ready to contribute to a neutral foundation. If your project is very immature, foundations are unlikely to be interested in your project, whereas a project with many users and good traction that just needs help moving to the next level would be much more likely to be accepted and successful under a foundation. For companies contributing projects, you’ll have a stronger case for moving it into a foundation if you have some contributors, and ideally at least one maintainer, from outside of your company. Contributors tend to be suspicious of company owned open source projects, especially ones requiring a Contributor License Agreement, given the recent rug pulls and relicensing behaviors from some companies over the past few years, so contributing a project to a foundation might make it easier to build a community around that project. 

The challenge with contributing open source projects to foundations is that as individuals and companies, you also give some of your control to the foundation. Typically, the project’s trademarks, repositories, websites, and other assets would be transferred to the foundation. Existing maintainers and leaders will usually keep their positions. However, neutral foundations (e.g., Apache, Eclipse, CNCF, Linux Foundation) often make sure that the governance is set up in a way that makes it easy for anyone to participate and eventually move into leadership positions, so as the contributing company or individual, you should expect for some leadership positions to transition to other people over the longer term. While this does mean giving up some control over the project, putting a project under a neutral foundation gives others more confidence that they can contribute as equals. 

You’ll still need to do the hard work of getting more contributors and building the community – you won’t automatically get this from the foundation. Most foundations have so many projects that putting a new project into a foundation may not get as much attention as you expect, and the foundation’s attention will be spread across all of those projects. The biggest misconception about putting a project under a foundation is that you’ll get immediate traction with more contributors and more adopters, but this still requires hard work from the people already participating in the project, so it’s important to set your expectations appropriately.  

One important note is that contributing a project to a foundation is almost always an ongoing commitment, not an exit strategy, so the contributing organization will likely be expected to provide staff and other support over both the short and long term. It’s also a permanent decision, and you aren’t likely to be able to take the project back after you’ve put it into a foundation, so it’s worth taking some extra time and doing some research to decide whether you should continue to own the project or whether it would be better to put it into a foundation.

Resources:

Photo by Hannah Busing on Unsplash

General

Governance Part 4: Creating Intentional Culture

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

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

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

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

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

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

Resources:

Photo by Mike’s Birds on Flickr

General

Governance Part 3: New Contributors and Pathways to Leadership

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

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

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

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

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

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

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

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

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

Additional Resources:

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

Photo by Paulius Dragunas on Unsplash

General

Governance Part 2: Defining Governance

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

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

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

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

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

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

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

Additional Resources:

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

Photo by Sarah Dorweiler on Unsplash

General

Governance Part 1: Why is it important?

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

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

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

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

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

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

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

Additional Resources:

Photo by Pierre Bamin on Unsplash

General

Demonstrating Organizational Value

Yellow shocked emoji with dollar sign eyes

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

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

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

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

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

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

Related blog posts:

Photo by Farhat Altaf on Unsplash

General

From First PR To Lifelong Impact: Helping People Thrive in Open Source

Slide in the background titled From First PR To Lifelong Impact: Helping People Thrive in Open Source with avatars of the 4 speakers who are sitting on tall chairs in front of the slide from left to right Matt Denny, Shuah Khan, Ruth Ikegah, and Dawn Foster. In the foreground are slightly out of focus audience members from the back of the room.

I spend a lot of time thinking about the sustainability of open source projects and the role that contributor sustainability plays in overall project sustainability. This involves more than just attracting contributors, but in ensuring they stay, grow, and thrive within our open source projects, and that can be a lot easier if we think outside of our traditional boxes and get creative about recruiting and retaining contributors.

Within the CHAOSS project, some of our most successful initiatives are driven mostly or partly by folks from our CHAOSS Africa chapter. We also have a CHAOSS Asia chapter that has recently re-started and is also driving some interesting work within the project. As a result, I’ve seen first hand some of the challenges, but also the rewards, that come from making it easier for people to contribute from countries that haven’t always been well-represented in many open source projects.

On a similar note, until recently, I was co-chair of the CNCF Contributor Strategy Technical Advisory Group where we were working to help CNCF projects grow their contributor bases. The CNCF mentoring programs were managed out of this group, and I was struck by how many mentees stick around after their time in the program with some mentees even becoming mentors! Another initiative within this group was the Deaf and Hard-of-hearing Working Group where I was inspired by all of the amazing work to help folks more actively participate in CNCF events and projects! This work was so successful that a second group was created by people from the blind and visually impaired community with similar goals of making it easier for people to participate.

All of this work got me thinking about how traditional pathways into open source don’t work for everyone and that we need to expand our contributor pipelines beyond the usual audiences if we want to have more sustainable open source projects where everyone can feel comfortable participating. This was the idea behind bringing together a panel of experts at the recent Open Source Summit in Denver where I led a panel discussion about this topic with Shuah Khan, Ruth Ikegah, and Matt Denny. I hope you enjoy this video of our discussion!

Note: A huge thank you to Sandeep Kanabar who helped put this proposal together, but was unable to attend at the last minute, and thanks again to Matt for stepping in on short notice! 

Resources and Links:

Related Fast Wonder blog posts:

Photo by The Linux Foundation used under the CC BY-NC 4.0 license.

General

The Impact of Funding for Sustainable Open Source Projects

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

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

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

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

Additional Resources:

Photo by Jason Leung on Unsplash

General

Strategy Before Metrics

Two chess pieces facing off on a chess board

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. 

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.

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