Improve the efficiency of your software development team with the RICE framework. Learn more at the upcoming APIStrat conference in Portland, Oregon.

The Developer Experience team at SendGrid is a small, but mighty force of two. We attempt to tackle every problem that we can get our hands on. This often means that some items get left behind.  At the outset, we surveyed everything that was going on in our open source libraries and we quickly realized that we needed to find a way to prioritize what we were going to work on. Luckily, our team lives, organizationally, on the Product Management team, and we had just received a gentle nudge and training on the RICE prioritization framework.

On our company blog, I wrote an article about how employing this framework, using a spreadsheet, helped us double our velocity as a team within the first sprint. Our development velocity doubled because the most impactful things for the time spent are not always the biggest things, but the biggest things tend to attract the most attention due to their size.

What is RICE?

RICE as an acronym stands for Reach x Impact x Confidence, all divided by Effort. This calculation allows you to get a score that weighs the following. Some of the definitions we use are a slight departure from Intercom’s original version, but this has been very effective for us!

The calculation:

Reach * Impact * Confidence



This gives us a score for every item in our list. Then, we sort our list in descending order by score. We realized, once we had a sorted list, that we accidentally made a Kanban backlog. We worked from the top of the list, keeping work in progress (WIP) to as much of a minimum as possible. WIP can be tough with open source, because we often have 20-30 issues waiting for a community member response. These items sit at the top of our backlog, and we look into them at the start of every day in the hope that we can clear them out of our WIP category.

Lessons Learned

Reach – The number of customers this will affect

One thing we learned about using RICE is making sure that we use consistent numbers for each of the variables in the calculation. It was very tempting for us, an email company, to use the “number of emails” sent as the Reach parameter. This worked until we started trying to evaluate tasks that didn’t have anything to do with our v3/mail/send endpoint. We eventually settled on number of customers using this library for this purpose”, calculating API user count and mail user count for the Reach.

Impact – A measure of the effect completing this project will have

It is easy to assume that every single item is a high or massive priority. It looks nice, gives you an ego boost, and totally messes up everything in your ranking system. Be honest with yourself about what is on your list. If things don’t really seem to be in the right place in your list (more on this below) then look at impact, because it’s probably artificially high, especially in context of the items around it in the list.

Confidence – How confident are we that we can sit down and complete this task today

We use a text-based selection from the list: None, Minimal, Low, Medium, High, and “with my eyes closed”.  These each translate into specific numbers for the calculation.

Effort – The number of story points will this take to complete

We use story points because this approach allows us to figure out the calendar length of a task rather than the aggregate of specific amounts of time spent on the task. To be more specific, this is the difference between “It’s going to take 3 hours” and “It will only take 3 hours of work, but it won’t be finished until Friday.” This is an easy trap to fall into, because new projects are exciting and we want to jump in and knock them out. That doesn’t mean that we can actually get a project that “will only take a couple days” done within the same month we started it. Life happens, your velocity calculation accounts for that — especially if you use an average over the last year (get out yer agile pitchforks!).

Letting the backlog win

We have learned the hard way with projects we really want to work on right now, that they are not always the right project at the moment. It is important to have confidence in the calculation and take the assumption that it is correct. That is, until you are looking at the list and realize that “Hey, item 15 really should be item 5. What’s going on here?” Look at your list in context of the other items, does the order feel correct? If not, why not?

We ended up using RICE as the baseline calculation for everything we do, but it is not the end-all. We added in calculation modifiers for company priority, due dates, and status — because something the executives have on the company roadmap, that has to be done in Q3, should be worked on right away. And, because we are using Kanban, the status of an item is important. Once you start something, it should stay at the top of the list until it is done, or you decide it is no longer necessary to complete it. Getting WIP completed, rather than backed up, is a good way to see the impact of your work and get a sense of accomplishment for yourself and your development team.

Matt Bernier is the Developer Experience Product Manager at SendGrid, where he spends most of his time digging into customer feedback in order to provide a World Class Experience for Developers with SendGrid.

Learn more in Matt Bernier’s talk — How We Doubled the Velocity of Our Developer Experience Team — at the APIStrat conference coming up Oct. 31 to Nov. 2 in Portland, Oregon.


Concepts such as decentralizing strategy, delegating direction, and fierce transparency in communication are part of the backbone of successful open source projects. In my presentation at Open Source Summit EU in Prague, I will explore how these concepts are not only applicable to volunteer-run organizations but can also help growing corporations avoid some of the coordination overhead that often comes with growing teams and organizations.

We’ll look at some of the key aspects of how project members collaborate at The Apache Software Foundation (ASF). After that, we’ll take a closer look at German FinTech company Europace AG, which decided to move toward self-organization two years ago. We’ll highlight parallels between Europace AG’s organizing approaches and those of open source projects.

Let’s start with some of the core values of ASF projects.

Community over Code

One main principle is the concept of “community over code” — which means that without a diverse and healthy team of contributors to a project, there is no project. It puts the team front and center, as highlighted in the Apache project maturity model.


Another core value to Apache projects is meritocracy — essentially meaning that there is no governance by fiat. There is no way to simply buy influence into projects — you have to invest time to gain influence. This directly translates to frequently given advice for how to get started with any given project: Focus on the things you are using yourself and fix what bothers you most essentially following a scratch your own itch kind of model. There is one level of indirection here: Committers and contributors can be paid either by their employers or as part of a consulting gig to increase their motivation to work on the topics that you are interested in.

Project independence

Be aware though that there is a strong principle of people participating as individuals on projects. That level of independence means that within an Apache project, there is no way to assign tasks to project members. Apache projects by design have a very flat organization with barely any hierarchy: Titles like Project Management Committee Chair (PMC Chair) are famous for coming with additional responsibility but no entitlement to task assignment. That means projects need a process for aligning people with potentially very diverse interests and itches to scratch. A key ingredient to coming up with workable decisions is making project goals and needs public and transparent — both in terms of asking for help and in showing appreciation and rewarding contributions that help the project. Another one can be found in an approach to integrating differing opinions and arguments in a “Yes, and” instead of a “Yes, but” fashion. This plays together very closely with the next concept.

Full transparency in open source projects

“What didn’t happen on the mailing list, didn’t happen” is one of the mantras for those involved with Apache projects. A high level of transparency is what makes Apache projects so easy to participate in across boundaries — whether they are geographic, corporate, or other. At Apache, mailing lists are treated as the point of reference for any decisions made. Thus, there is full transparency into the historic record of all open source projects.

Of course, with that entirely open and transparent model comes responsibility: A lot of decisions can be taken in the open. People tend to show better behavior when under public scrutiny. However, discussions involving interpersonal issues are best kept out of public sight. This is particularly important in a digital age where deleting statements made online and mirrored worldwide is pretty much impossible.

Project autonomy

Technologically, Apache projects are very diverse. However, when unified under one organization with a common focus on community, meritocracy, and communication patterns, there is a lot of freedom and decentralized decision making.

One important piece in growing the ASF as a whole was giving autonomy to each project. Still there are a couple topics that each project has to deal with: It’s great having one central entity answering questions on, for example. trademarks, licensing, or software patents. However, these entities controlling each of the 300 or so top level open source projects won’t scale. Instead, Foundation-level services serve as guidelines for Apache open source projects to manage their own activities in these areas. As a result, each project is supposed to have some people knowledgeable in those topics.

Open source patterns in the enterprise

In the past decade, people in the open source space have successfully brought several of these concepts to their respective employers — either in the form of open development, inner source, or open organizations. Meanwhile, ideas of transforming traditional hierarchical organizations into self-organized, open organizations found their way into concepts like sociocracy and holacracy.

Europace AG decided to move toward self-organization roughly two years ago. Looking at what was established during these two years, we see quite a few similarities to how nonprofits such as the Apache Software Foundation and The Linux Foundation work with open source projects:

Decentralization and autonomy

Europace AG is a tech company experienced with XP and Scrum, and in 2015, they began a journey toward self-organization, looking into holacracy and sociocracy frameworks. Organizationally, there are roughly 200 people split into four fairly autonomous technical units, each one of which is responsible for one business product of the company. Units are autonomous in how they self-organize: Some chose fairly standard Scrum-based software development in iterations and standard rituals. Others went for sociocratic or holacratic models. By organizing in circles, employees are given more influence over how decisions are made that affect their daily work. Backing for this level of autonomy can be found in the company’s own principles, where self-organization and decentralization are outlined as one of the four important values and are actively supported by the board.

This is not unlike Apache, where open source projects operate independently and autonomously in how they develop their software and self-organize (that is, provided they make sure that project governance remains independent of one single player, security issues are being dealt with, and legalities like licensing, patent issues, and trademarks are taken care of).

Transparent decision making

Everyone working for and with Europace AG is located in one timezone, and Europace AG itself has only one site. Nonetheless, there are good reasons to look at how decisions are made in distributed open source projects: Establishing a remote friendly communication model can help support employees with family, and deal with long commute distances. Apart from these obvious benefits, there are a few effects that aren’t quite obvious:

While an asynchronous communication model won’t lead to decisions happening faster, it can help with reducing the amount of interruptions caused by face-to-face meetings: By sharing a proposal before the actual meeting happens and providing a means to exchange ideas around that proposal can help with understanding people’s opinions, issues and suggestions with respect to the proposal. It can help with making that understanding transparent to everyone interested in the topic up front. Combined with a “Yes, and” philosophy, this can help form consent in the team quickly.

Organizational Groups

Splitting roughly 200 employees into just four units creates groups that are bigger than typical “2 pizza sized teams” often deemed ideal for software development teams. As a result, each unit had to figure out how to create sub-groups that can work well as teams.

A common approach was to create cross-functional feature teams, comprising both software developers and people familiar with financial domain (and people with backgrounds in data analytics, UX, etc. as needed). Those are called feature teams in anticipation of the fact that they aren’t necessarily particularly stable: Each week, there is a check point people can use to decide to change feature teams depending on where they are needed most. Decisions related to governance as well as product strategic aspects are delegated to the team itself. As a result, team members need a good understanding of the current product direction in terms of features and usage.

For tasks and topics that tend to fall under the general topic of “organizational operations” or “decision making with dependencies,” people organize themselves in circles, which are essentially groups of people interested in participating in making a decision related to a specific topic. Despite a lot of communication still happening face to face, some circles also set up a Slack channel that is open for all to join and participate. This level of transparency is crucial in elevating trust people have in those decisions.

Each of these circles can come with dedicated roles: Secretary being the one taking over meeting minute creation, a Lead Link making sure that “things will actually get done” and communicated to the people needing the respective information. While people can volunteer for these roles, at the end of the day these roles get filled through nomination by the team. This is not unlike Apache projects where new committers, PMC members, and even Foundation members are elected after nomination. On one hand, this kind of model shows a certain amount of appreciation for the work these people are doing. On the other, it helps with promoting people into these roles who according to their own self-assessment might not have confidence to take on the role.

Put the human first 

Much like Apache puts community development front and center with its open source projects, Europace AG puts team collaboration into a central position. This means that each employee is responsible for raising issues with team climate, and they are supported by a team of professional coaches, moderators, and mediators with a deep understanding of human communication.


When moving toward self-organization, corporations can learn a lot from how open source projects organize themselves. Europace AG is on the journey toward moving more power away from traditional formal structures, making it available for the people in purpose-driven, circle-based organization. It will be interesting to watch how Open Source project management, governance, and communication patterns can be applied within corporate contexts.

Isabel Drost-Fromm is Open Source Strategist at Europace AG Germany. She is a member of the Apache Software Foundation, co-founder of Apache Mahout and has mentored several incubating projects. Isabel is interested in all things FOSS, search and text mining with a decent machine learning background.

At the recent Open Networking Summit, the SDN/NFV community convened in Santa Clara to share, learn, collaborate, and network about one of the most pervasive industry transformations of our time.

This year’s theme at ONS was “Harmonize, Harness, and Consume,” representing a significant turning point as network operators spanning telecommunications, cable, enterprise, cloud, and the research community renew their efforts to redefine the network architecture.

Widespread new technology adoption takes years to succeed, and requires close collaboration among those producing network technology and those consuming it. Traditionally, standards development organizations (SDOs) have played a critical role in offering a forum for discussion and debate, and well-established processes for systematically standardizing and verifying new technologies.

Introduction of largely software (vs. hardware) functionality necessitates a rethinking of the conventional technology adoption lifecycle. In a software driven world, it is infeasible to define a priori complex reference architectures and software platforms without a more iterative approach. As a result, industry has been increasingly turning to open source communities for implementation expertise and feedback.

In this new world order, closer collaboration among the SDOs, industry groups, and open source projects is needed to capitalize upon each constituent’s strengths:

  • SDOs provide operational expertise and well-defined processes for technology definition, standardization, and validation
  • Industry groups offer innovative partnerships between network operators and their vendors to establish open reference architectures that are guiding the future of the industry
  • Open source projects provide technology development expertise and infrastructure that are guided by end-user use cases, priorities, and requirements

Traditionally each of these groups operates relatively autonomously, liaising formally and informally primarily for knowledge sharing.

Moving ahead, close coordination is essential to better align individual organizations objectives, priorities, and plans. SDN/NFV are far too pervasive for any single group to own or drive. As a result, the goal is to capitalize upon the unique strengths of each to accelerate technology adoption.

It is in the spirit of such harmonization that The Linux Foundation is pleased to unveil an industry-wide call to action to achieve this goal.

As a first step, we are issuing a white paper, “Harmonizing Open Source and Standards in the Telecom World,” to outline the key concepts, and invite an unprecedented collaboration among the SDOs, open source projects, and industry groups that each play a vital role in the establishment of a sustainable ecosystem which is essential for success.

The introduction of The Linux Foundation Open Network Automation Platform (ONAP) is a tangible step in the direction of harmonization, not only merging OPEN-O and the open source ECOMP communities, but also establishing a platform that by its nature as an orchestration and automation platform, must inherently integrate with a diverse set of standards, open source projects, and reference architectures.

We invite all in the community to participate in the process, in a neutral environment, where the incentives for all are to work together vs. pursue their own paths.

Join us to usher in a new era of collaboration and convergence to reshape the future.

Download the Whitepaper

Engagement in an open source community leads to collaboration, says Jason Hibbets, community evangelist at Red Hat. And social media is one good tool that projects can use to help increase engagement in their communities, he adds, “because you can reach a broad audience at pretty much no-to-low costs.”

Hibbets will discuss how Red Hat has increased engagement with one such social media tool, Twitter chats, in his talk at Open Source Leadership Summit in Lake Tahoe on Feb. 16, 2017. Here, he shares with us some of his reasoning behind why engagement is important, some best practices for increasing engagement, and a few lessons learned from Red Hat’s Twitter chats. Why should an open source project be concerned with building engagement?

Jason Hibbets: Let’s first start with why have a community in the first place? A community is a group of people who come together with a common vision, collective passion, and shared purpose. Communities bring together a diverse group of people to share work and can accomplish more than individuals can alone.

Many open source projects exemplify these qualities and come together to form a community. Typically, an individual wants to solve a problem (scratch their own itch) and it just so happens that other people are trying to solve a similar problem. When communities collaborate to solve these problems together, it leads to better outcomes and results.

So, why should leaders be concerned with engagement? Engagement leads to collaboration. And if communities can collaborate, then work gets done and they can achieve something together. As an individual, your knowledge is limited. There will be a point when you want feedback, need advice, or get stuck. If you have an engaged community, you are building in a human-powered support system. What are some of the best practices, in general, for increasing engagement and gaining more active followers?

HIbbets: I’ll share two best practices, but believe me there are a lot more. The first is to provide a safe environment. The second is to create value.

Having a well-written Code of Conduct and enforcing those rules is a foundation for having a safe and inviting environment. This can ultimately lead to increased participation from a more diverse group of contributors and creative problem-solving with faster, more innovative solutions.

A second best practice is to provide value. In the community programs I’ve built, you need to think about why a person would volunteer their precious time to contribute–this is commonly referred to as the “what’s in it for me?” question.

When contributors are finding value in the community, they are more likely to be engaged. And if they are more engaged, they can become your advocate. Which can lead to the best type of marketing for your community, word-of-mouth recommendations.

For more best practices about community building, I recommend reading The Art of Community by Jono Bacon. Why is social media, and Twitter in particular, a good place for open source projects to do outreach?

Hibbets: In general, social media is a good place for outreach and amplification because you can reach a broad audience at pretty much no-to-low costs (other than your time). The challenge, of course, is putting in the investment and time to build a following, a content strategy, and determine the right way to fit into each social media community.

Twitter is a great platform for open source projects because of ease-of-use and, for now, unfiltered streams. Engagement levels can be higher, and people follow specific hashtags. Once you filter through all the noise, there is a lot of valuable information that can be found for open source communities.

And bonus, there’s a lot of open source behind each Tweet. What is a Twitter chat?

Hibbets: I like to describe a Twitter chat as a public-facing conversation at a set time, using Twitter as the platform and a hashtag as the way to follow. It’s the equivalent of using a chat room in IRC (Internet relay chat) or similar chat functionality, but instead, you’re using and following a hashtag on Twitter. What it boils down to for our Open Organization community on is to have focused discussions on topics with several source matters experts invited to participate and help lead the discussion. For example, last October, we talked about the intersection of DevOps and Open Organizations.

There are several different formats Twitter chats can take. We chose to do more of a live event where we are actively Tweeting questions for an hour and watching the responses come in. My team leads the conversation, monitors the responses, and learns from our community. Participants learn from other participants and make valuable connections that enhance their network. How do you measure progress and what’s the goal?

Hibbets: My talk at the Open Source Leadership Conference will be on building a community using Twitter chats for our Open Organization community. The examples I will use come from my experience doing this for the Open Organization community, so  I’ll focus on my response on that aspect.

First off, the goal is two-fold: to build awareness of our community and attract new people to join the conversation.

By hosting a Twitter chat, we are able to have an amazing conversation with our community. Seeing the engagement, responses, and interactions really makes me proud as a community manager. We are having a conversation that is engaging to people with vastly different roles–from solutions architects to consultants, and open source project leaders to people managers outside of open source. We have a diverse audience of participants.

So, how do we measure success? There are two main metrics we are concerned with: the number of unique participants and how many Tweets they generate. From there, we can calculate more impressive numbers like total reach and total timeline exposures. These numbers can impress managers, which is helpful, but the more meaningful metrics are really around the number of active participants as well as how many new people continue to join.

To give you some context, on average, we have about 30-50 unique participants generating about 300-400 tweets in about an hour. What did you learn from hosting regular Twitter chats with your community?

Hibbets: There are three things we learned I’d like to share. First, there are people out there who not only want to have this conversation in the first place, but want to continue the conversation. The number of repeat participants that come back to our Twitter chats is high for the Open Organizations community. .

Second, being prepared makes our “live” events successful. We did a number of things (which I cover in extreme detail in my talk) that makes our event run smoothly. A few examples include promoting your Twitter chat in advance, preparing your questions ahead of time, and sharing your questions with invited guests in advance.

Third, having guest hosts and source matter experts is critical. Nothing draws a crowd more than a crowd, right? We found that inviting experts to join us and putting them in the spotlight worked really well for our community building efforts.

Join us for a future #OpenOrgChat Twitter chat to see what it’s all about.

Want to learn more about what it takes to grow an open source project? Tune in for the free live video of Open Source Leadership Summit. Sign up now!

The following is adapted from Open Source Compliance in the Enterprise by Ibrahim Haddad, PhD.

A successful open source management program has seven essential elements that provide a structure around all aspects of open source software. In the previous article, we gave an overview of the strategy and process behind open source management. This time we’ll discuss two more essential elements: staffing on the open source compliance team and the tools they use to automate and audit open source code.

Compliance Teams

The open source compliance team is a cross-disciplinary group consisting of various individuals tasked with the mission of ensuring open source compliance. There are actually a pair of teams involved in achieving compliance: the core team and the extended team.

  • The core team, often called the Open Source Review Board (OSRB), consists of representatives from engineering and product teams, one or more legal counsel, and the Compliance Officer.

  • The extended team consists of various individuals across multiple departments that contribute on an ongoing basis to the compliance efforts: Documentation, Supply Chain, Corporate Development, IT, Localization and the Open Source Executive Committee (OSEC). However, unlike the core team, members of the extended team are only working on compliance on a part-time basis, based on tasks they receive from the OSRB.


Compliance teams

Various individuals and teams within an organization help ensure open source compliance.


Open source compliance teams use several tools to automate and facilitate the auditing of source code and the discovery of open source code and its licenses. Such tools include:

A compliance project management tool to manage the compliance project and track tasks and resources.

A software inventory tool to keep track of every single software component, version, and product that uses it, and other related information.

• A source code and license identification tool to help identify the origin and license of the source code included in the build system.

A linkage analysis tool to identify the interactions of any given C/C++ software component with other software components used in the product. This tool will allow you to discover linkages between source code packages that do not conform to company policy. The goal is to determine if any open source obligations extend to proprietary or third party software components. If a linkage issue is found, a bug ticket is assigned to Engineering with a description of the issue in addition to a proposal on how to solve the issue.

A source code peer review tool to review the changes introduced to the original source code before disclosure as part of meeting license obligations.

A bill of material (BOM) difference tool to identify the changes introduced to the BOM of any given product given two different builds. This tool is very helpful in guiding incremental compliance efforts.

Next time we’ll cover another key element of any open source management program: education. Employees must possess a good understanding of policies governing the use of open source software. Open source compliance training — formal or informal — raises awareness of open source policies and strategies and builds a common understanding within the organization.

Open Source Compliance

Read the previous article in this series:

The 7 Elements of an Open Source Management Program: Strategy and Process

Read the next articles in this series:

How and Why to do Open Source Compliance Training at Your Company

Basic Rules to Streamline Open Source Compliance For Software Development

John Willis — a leader in the DevOps movement — is hosting a series of webinars to accompany the free Introduction to DevOps: Transforming and Improving Operations training course from The Linux Foundation and edX. Last month, he provided a thorough introduction to the course and offered tips and tricks on how to get the most out of it. If you missed this introduction, you can watch the complete webinar replay on demand.

There are several ways to approach this course. Willis described four different approaches to consider depending on your needs and interests:

  1. Watch just the included videos in the free course (15 hours)

  2. Read the following suggested books and then do Step 1 (30 hours total)

    1. The Phoenix Project — a novel by Gene Kim about bottlenecks, constraints, theory of constraints, importance of flow, a modern day re-imagining of the book The Goal

    2. DevOps Handbook (co-authored by John Willis)

  3. Steps 1 & 2 + watch the additional suggested videos, read suggested blogs, and white papers (50-60 hours total, including 15 hours of videos, 15 hours of suggested advanced research, two books, and 10 advanced reading recommendations)

  4. Treat it like a college course doing all of the above and all the recommended reading (estimated 120 hours)

Hear Willis’s advice in the video clip below:

Attend Office Hours Webinars

Attending Willis’s office hours webinar to get your DevOps questions answered is another great way to make the most of this free course. Throughout this multi-webinar series, Willis will share his insights and guide participants through the course. In each upcoming webinar, he will provide a quick chapter summary, leaving plenty of time to answer your questions and enhance your training experience.

In the first session, presented in December, Willis explained the DevOps concept, which he says can help organizations develop and deliver services more quickly and reliably. In session two, earlier this month, Willis covered Chapter 1 of the DevOps course then opened up the session to answer questions in the style of college office hours. You can watch the replay of session two on demand.

In session three, Willis will briefly cover Chapter 2 of the training course and address your questions.

Join us on January 31, 2017 for the next installment of this webinar series: Intro to DevOps with Course Author John Willis, in which Willis will provide a brief overview of Chapter 2 and take your DevOps questions! Register Now >>

John Willis is the cohost of DevOps Cafe Podcast ( and a co-author of the DevOps Handbook. He is also the course author of Introduction to DevOps: Transforming and Improving Operations, a free course from The Linux Foundation and hosted on

One of the core tenets of DevOps is learning and sharing, said John Willis, co-author of the DevOps Handbook in an interview on “Individuals who are passionate about the health and performance of their organization find these patterns personally fulfilling,” he said.

Willis, who has been a leader in the DevOps movement from the beginning, will share his insights in an upcoming “Introduction to DevOps” webinar series hosted by The Linux Foundation. According to Willis, a primary advantage of DevOps is that it can help organizations go faster while being more reliable. And organizations that deploy faster and deliver services more quickly are better at resolving issues.

In this multi-webinar series which starts next week, Willis will help guide participants through the free Introduction to DevOps: Transforming and Improving Operations training course, which is available from In each webinar, Willis — the course author — will provide a quick chapter summary, leaving plenty of time to answer your questions.

Join us Tuesday, December 13, 2016 at 10:00 a.m. Pacific for the first webinar session in which Willis provides a brief overview of the complete course, explaining the topics to be covered and describing the rationale for the course.

Sign up for the webinar now!

There are four essential questions a company should ask before it decides to create an open source project, according to Duane O’Brien, open source programs evangelist at PayPal.

  • Who cares?

  • Are we still using it?

  • Are we committing our own resources?

  • Can we develop it all in the open?

This framework, developed by O’Brien’s boss Danese Cooper, is useful in vetting internal software for release as open source projects.

In a nutshell, a company shouldn’t open source software that no one else cares about, that they themselves are not using, that they will not commit developer resources to maintaining, or that they continue to develop in secret without community inclusion. (You can see more details and the rationale behind each question in his blog post on earlier this year.)

“If no one contributes it becomes unmaintained abandonware – a pollutant in the open source ecosystem,” O’Brien said in his talk on the four questions at LinuxCon Europe yesterday.

But what if the answers to these questions are consistently “no?” This is itself a litmus test for a company’s open source knowledge and culture.  

“Use these questions as pointers about what’s going on in the company,” O’Brien said.

1. Who cares?

“If you’re consistently getting: “no one cares,” it’s a good indicator that your technical community isn’t very well connected to the industry,” O’Brien said.  Open source advocates within a company should consider engaging in programs that encourage engineers to join communities and technical discussions. Some examples are:

  • start publishing a podcast

  • start publishing blog posts

  • encourage employees to attend meetups and talks

  • provide travel stipends for employees to attend conferences

  • bring outside experts in to give talks.

2. Are we still using it?

If a company only open sources projects they’re not using anymore, that’s bad corporate practice, O’Brien said. It damages that company’s reputation in the open source community.  

Instead, he recommends looking for what has replaced that defunct code and consider that as an open source contribution.

“Look for exciting things and mine them for open source projects,” he said.

3. Are we committing our own resources?

“If we aren’t committing resources, we’re probably pushing employees and engineers too hard,” O’Brien said. “They should never be asked to maintain open source projects on their own time.”

If a company never commits resources to open source, “it’s also probable that managers don’t understand what a healthy relationship with the open source community looks like,” he said.

More management training on the importance of open source software and how to best use it strategically may be beneficial.

4. Can we develop it all in the open?

And if code cannot be released publicly because developers don’t want anyone else to see it, you may have code quality issues. Or if they’re not willing to engage with the community, which is required to develop in the open, “then there are probably culture issues,” O’Brien said.

These issues can be addressed through employee training and improved code review processes.

Regardless of a company’s answers to the four questions, one of the best things they can do is share what they’ve learned with other developers and companies. It’s good source material for blog posts, white papers, and talks: what you tried, why it didn’t work, and what you’d do next time.

“So the people who come after us can see where we went wrong previously,” he said, and the entire industry can move forward.