4

Aligning the Business Value of Open Source for Your Employer

If you’ve read Chapter 1 and Chapter 2, you’ve hopefully come away with some concrete motivations for using open source and starting an open source project. And if you’ve made it to this chapter, you are probably thinking, “there is some great code at my company we should open source!” That’s the right attitude!

However, there’s a lot more than meets the eye when it comes to an employer seeing the value of contributing to an open source project, let alone starting one. As an individual deciding to contribute to open source or start an open source project, the justification is usually quite simple: you have something interesting to you that you want others to benefit from, or are using a project and you see something that you want to fix or improve – what is often referred to as the scratch-your-own-itch pattern. You may also find the work that a project is doing helpful and just want to help out – maybe writing some documentation or providing feedback on a pull request – more itch-scratching.

For companies, scratching your own itch is noble but not enough – they need to see how this benefits them as a business overall, which is often termed “enlightened self-interest.” Software developers are considered less than business-savvy in many organizations, and due to that perception, the conversation on open source stops there. This speaks to the need to connect the value of open source to business value, which in the past few decades, we’ve seen come together. It has been a bumpy road at times to align business models with open source, which is no different from how the disruptive technologies of the past took time to find a suitable business model.

In this chapter, I’ll lay the groundwork to help you get your company into open source, either contributing to or launching a new project. This is merely the tip of the iceberg, and we will look at further resources toward the end that can help you establish open source as part of your company’s strategy.

Why would a company want to open source code?

Getting support for open sourcing code within an organization requires first understanding what the motivations are for even doing so. It requires you to think with a business mindset, which at the end of the day comes back to costs and revenue. Sometimes, this can be framed in more long-term thinking, but being persuasive when championing this kind of initiative also requires citing some short-term benefits. Let’s look at what tend to be the primary motivators.

Lowering development costs

The bottom line is something every company thinks about, and this tends to be a major motivation in looking at open source. In software development, there are costs both in terms of initial development and maintenance, which includes new functionality, as well as fixing bugs and resolving security issues. Staying on top of this can be quite an endeavor.

One aspect of the development costs that companies don’t often think about is the specialization involved in software development. If you go back to the early 2000s and before, the most common software developer was what is known as the full-stack developer, meaning someone who had broad knowledge and expertise in different technologies and languages. For example, a full-stack developer would be able to write the frontend code for a website in HTML, JavaScript, and CSS, the business logic in something such as PHP, Python, or Ruby, and manage the database backend using MySQL or PostgreSQL. If you are a software developer, you know there are technological differences not only between each of those but also in how you would approach scaling, performance, security, and maintainability with each of them. For the software developer today, those layers have become more complex, moving from simple JavaScript calls to complex frameworks such as Bootstrap, from monolithic applications to micro-services, and often not just one database backend but multiple ones that may involve different approaches and methodologies.

For an organization today, even a modest software development company, hiring software developers with expertise in each area is an endeavor. In some cases, there may only be a handful of individuals that have expertise in a particular tool. For example, if you need to build a largely static website that has some template logic to keep multiple areas of a website in sync, you could define a template language and build some scripting to automate it – or you could use something such as Jekyll or Hugo, which has all this ready to go. That way, you don’t need a developer to maintain this script, which will undoubtedly break at some point, or the template language will need to be extended for different data types, but instead use the build functionality and templating language that either Jekyll or Hugo provides. This not only saves the company time and effort but also means they don’t need staff with deep expertise, just somebody who understands how to use the tool itself. This simplifies hiring by looking at the skills around a project and lets them be more flexible with their developer resources.

Adding new features/functionality for customers

Let’s say your company is building out a task management tool, and a customer comes in with this request: It would be great if all of a user’s tasks were listed on their calendar to help them plan ahead and coordinate with the other meetings on their calendar. One route would be exploring how to build integration into a single calendar tool, such as Microsoft Outlook or Google Mail; another would be writing a custom iCal server that implements the iCalendar standard. Or, you could look for a library that is able to deal with the entire iCal standard. Which one would you choose?

This is exactly the kind of sweet spot where open source comes in, the ability to provide a piece of functionality to solve a particular problem that exists across a wide variety of use cases. You could argue it comes from the Unix and free software heritage, where each tool solves a particular problem (and does it well) and is designed to work in conjunction with other tools. As with the previous point on lower development costs, a company doesn’t need staff to understand all the ins and outs of these libraries or tools; they just need to be able to use them.

Another piece of this equation is being able to improve libraries and tools to make the integration or customer experience better. For example, if we look at the iCal example, maybe the company’s development team identifies a compatibility issue with a particular calendar client that uses the iCal endpoint (if you haven’t worked with iCal before, note that clients can be incredibly picky on things such as whitespace and line endings). Not only could they report the issue but they could also provide a test case, and even fix it. If this wasn’t open source, they would have to rely on the vendor’s timeline and support team, which could take weeks, months, or even years; in open source, it’s a question of submitting a patch and getting it merged into the main code base. As a bonus, the company then doesn’t need to maintain a version of the tool with the fix – this is called working upstream (which was discussed in Chapter 2, What Makes a Good Open Source Project?) and makes it easier to introduce new features and functionality to your company’s product without any work on your end at all!

Faster time to market

The previous two points on why a company would open source code focused on the developer alignment angle in using open source as a way to optimize a company’s developer investments. Another part of that optimization is velocity – or better put, how a company can build software faster.

If we look at the classic Facebook, Apple, Amazon, Netflix, and Google (FAANG) companies (Facebook now being Meta), the differentiating factor for all of them was building their solutions on top of open source. Facebook heavily used PHP in its rise to popularity, Apple built Mac OS X using many parts of FreeBSD and the Mach kernel projects, and we’ve seen Amazon, Netflix, and Google use open source, as well as build a lot of open source for the larger open source community to use and contribute to. The same pattern has been used numerous times with other technology companies, with numerous start-ups forming from open source communities or starting open source communities of their own to drive innovation.

What is often a big question to those outside of open source is, “Why put technology like that out there for anyone to use? Couldn’t open sourcing this code jumpstart a competitor in the space to overtake you?” It’s a fair observation, but companies look at it as a trade-off; is there more value in owning all the code and IP, or is there more value in getting a solution to market faster? And furthermore, what layers of the stack have value?

Apple, when they made the move from Classic Mac OS to Mac OS X, realized that the value was at the user experience level, so building their own operating system kernel didn’t make a ton of sense (it also didn’t help they were coming off the heels of the Copland project, which is considered one of the biggest failures in software development history [1]). A big driver was the need to move quickly to achieve a more modern operating system, as the Classic Mac OS was aging and didn’t include several key features, such as pre-emptive multitasking, protected memory, access controls, and multi-user management, so building on top of a kernel and operating system that had all of those things got them to market faster.

As we looked at in previous chapters with the value of open source being ecosystem building, there is a secondary benefit – not just getting to market faster but also establishing the market faster as well. Cloud Foundry comes from an open source project launched at Pivotal Software back in 2011, with the idea that starting this project would make it a standard for anyone building multi-cloud Platform-as-a-Service (PaaS) applications. This idea did come to fruition, with several vendors and cloud providers bringing support for Cloud Foundry, thus not only helping solutions come to market faster but at the same time establishing Cloud Foundry as the standard faster – and by proxy, Pivotal Software as a market leader.

The ability to focus investments

I will often chat with companies when they are looking at open sourcing some code that they have written and when the discussion moves to the value of open sourcing the code that they have, I draw the analogy to other services they might have for their business.

For example, you don’t often see the CEO emptying the trash cans around the office; most commonly, we see that as a contracted service. Emptying trash cans is a commodity, meaning it’s something a broad scope of people could do. Often, the cost itself of a commodity service is low because economies of scale kick in; for example, if a company shares a building space with four other businesses, one person could empty all the trash cans instead of four different people each cleaning different offices.

The same idea applies here as well – as I mentioned before, you don’t have to have specialists for each layer of your application, just ones for the specific parts that are critically important to your business. It’s similar to how cloud computing has reduced the need for each company to have a data center administrator; if you build your application on top of a framework such as Cloud Foundry, you just need experts in Cloud Foundry and not each of the underlying components. This makes it easier to focus a company’s investments, attract talent, and generally execute better as a business.

With this background on why a company would participate in the open source ecosystem, let’s now talk about how to build that support internally to open source code.

Getting support for open sourcing code internally

Now that you know why a company would open source code, let’s walk through what we must consider as we go through the process of proposing to open source code. Note that every company works a bit differently, so many of the points I’ll cover are at a higher level; however, the general concepts are key ones that any company will need solid answers to.

Reviewing what’s out there already

Open source projects are consistently under-resourced. Even if there are enough developers, those developers might not have the bandwidth to write tests, build documentation, triage incoming issues, respond to questions, and deal with security issues. Working together helps make projects more efficient, have a larger impact, and address more features and use cases than working alone.

Before you start a new open source project, research other ones out there that might solve the same problem. As you review them, consider these questions:

• Does the project cover the same use cases as mine?
• Is it built using the same language, framework, or technology stack?
• Are there multiple companies contributing to the project, or just one?
• Does the project have a track record of accepting community contributions promptly?
• What license is used, what IP policies does the project have, and are they compatible with our needs?

If you answered yes to all those questions, contributing to that project is likely a better choice than starting a new one.

Even if there are some no answers, that doesn’t necessarily rule out contributing to versus starting a new project. For example, if you are looking to distribute a product and use the open source project as a part of that product, and that project is under a GPL license, that might be considered a showstopper. Before you do that, reach out to the maintainers and see whether they would be open to changing to a more permissive license; often, maintainers aren’t overly savvy in open source licensing or might not realize the challenges a license might have regarding adoption. I’ve reached out to the maintainer of a project using a GPLv3 license before, for example, and said “Any chance you could change to Apache 2?” and the maintainer has come back and said “Sure!” if it’s been fairly trivial for them to do so. I will note that this tends to be more realistic if the project has only one or just a few contributors, but larger projects likely won’t be as receptive.

Building the business case

Taking the general motivators from the previous section, you first need to work on building out a business case for why to open source a particular bit of code. There could be a multitude of reasons for it, including the following:

• The code isn’t all that specific to the company, not mission-critical, and could benefit from the involvement of external people
• Developers are looking to scale up the code or have run into a challenging problem and could use the help of broader expertise
• The code is related to an open source project that the company is using, either building on the project or deriving code from it, and the use case is likely applicable to others, so upstreaming it would be good for the company and the project

Starting to build a business case around open source is fairly similar to building business cases in general, usually covering a few specific points:

• First is the problem statement. What is the challenge the company has today? Examples could be low bandwidth for the team to maintain the code or not having the expertise to continue development, or maybe it’s more opportunistic, such as identifying a gap in the market or a challenge with a common integration framework between multiple solutions.
• Second is outlining the solution. This could be to start a new open source project or contribute to an existing open source project – which is a topic we will dig more into later in this chapter. What is key at this stage is ensuring you can connect the problem to the solution succinctly and showing how the solution provides a way to address the problems raised simply.
• Third is identifying the steps forward and what is needed to get there. Think in terms of the internal tactical pieces (legal reviews, engineering reviews, and marketing reviews – we will get into all of these things later in this chapter), but also budget needs, briefing and getting alignment with outside partners, and aligning the internal resource support that is needed.

Let’s take a look now at how to build a business case more practically.

An example business case for open sourcing code from a company

Let’s look at an example business case here. A project I worked on in the past was the COBOL Programming Course, which was launched by Open Mainframe Project in April 2020, and while this wasn’t their exact business case, this is how I would imagine it:

• Problem: COBOL is a language heavily used in critical applications in finance, insurance, healthcare, government, and more. The new talent pool coming into COBOL is much smaller than the talent pool approaching retirement, and COBOL as a language is developed using tooling that is different from what a software developer uses today.
• Solution: Develop a programming course for COBOL, which teaches COBOL development using Microsoft Visual Studio Code and Zowe Explorer, and make it available as an open source project so that it can be broadly used by individuals to learn COBOL and by companies for internal training.
• Next steps: First, we will need to take the various learning materials around COBOL and fund building a course; this could be done in collaboration with an academic institution that might be interested in these materials for their classwork. Then, we will need to align a few industry partners to form a steering committee, set up a GitHub site, work with other organizations in the mainframe space, such as Open Mainframe Project, to provide a neutral home, make a public announcement, and launch the work. This will require two to three Full-Time Employee (FTE) resources at launch and ongoing fractional resources to support and drive the work.

The preceding outline is rather high-level both to keep this chapter from getting too long and also as a guide for thinking about the idea more succinctly. One thing to note in the early stages here is you want to leave some gaps open to have areas where others can fill in and provide support; in an open source project, the value of people outweighs that of funding, as people make the real difference in its success (or failure).

Here’s another example more suited toward contribution to an open source project, where a company that will remain nameless was debating whether or not to continue to develop its own database interface layer, or leverage and contribute to another one:

• Problem: We’ve built our own database interface layer, which has served us well for many years, but is becoming hard to maintain. Additionally, we want to be able to support additional database backends and it’s hard to implement them because of the design choices made.
• Solution: Review the existing database interface layers used and see which one most closely fits our needs. While we know it won’t be a drop-in replacement, we do know that we can contribute some of our concepts to these projects and they will likely see value from that, along with more usage from embedding it in our product.
• Next steps: Pull together an architecture committee to review the open source database interface layers and make a recommendation on which one to move forward with. We then need to do a gap analysis on what functionality is missing and work with the upstream community to contribute these back to the project (this likely will require legal review for licensing compatibility). We will probably require two to three FTE resources at first, which is slightly more than the size of the team maintaining that piece, but we anticipate we’ll be able to reduce to less than one FTE equivalent once the transition is complete.

What’s good in this example is the disclosure that the investment upfront will be higher in terms of resources, but it will reduce to less than the present investment over time. Setting expectations appropriately is a real key at this stage, especially giving yourself space, as you will hit bumps along the way.

Getting allies

Now, it’s time to start shopping around the business case within the organization. This is where each organization is a bit different, as there will be not only different personalities but also other key people who can help influence the decision. You know your organization best, so use this as a guide for the types of allies you will need:

• First, you need a budget ally who can help fund the time, effort, and expenses involved. There are a lot of pieces involved in open sourcing a project, including legal review, engineering work, marketing/PR, and community management, and these require personal time investment, as well as the funding to do the work. The budget ally will need to see how the investment will pay off in the long run.

A well-crafted business case will go a long way and the budget ally will also be able to add perspective on things you might not see. For example, maybe they know that there are team members close to retirement, and there are concerns about re-staffing. Maybe there are some discussions around adjusting focus and goals, and the open sourcing discussion is timely. Perhaps this person shares some hunches you have, maybe even with past experience in open sourcing code, and can give you support and advice along the way. Organizations are largely driven by cost, so while the budget ally isn’t the only key stakeholder, they need to be on board for you to have any success.

• The second will be technical allies. These can be software engineers, architects, or managers that are currently involved with the code and are expected to be involved in the future or impacted by the open source proposal. Often, these technical people are familiar with open source, and the idea of being part of the project will be exciting for them (or they may have had a bad experience and be put off from their experiences of open source as well). You may also have people with no familiarity with open source, or only experience from a distance, meaning they’ve heard of it and are skeptical, much like the example we discussed in Chapter 1, The Whats and Whys of Open Source.

Either way, you need their support, as they will be doing the technical work at the end of the day. In addition, you will want to set the expectation of how to work in an open source community, meaning design and feature discussions should happen out in the open, releases should be planned within the community, and simple things such as the bug tracker should be open resources. Often, I see companies open source code and keep all the development meetings and scrums within the company itself; helping set a good pattern at the onset not only ensures success for the project but also sets the proper habits for the internal development teams. We will dig more into this in Chapter 5, Governance and Hosting Models.

• Finally, and this might not be needed in all scenarios, is an executive sponsor. This might be the same person as the budget ally, but the big distinction is that they will have sway in ensuring this effort stays as a strategic priority, which makes it easier to allocate more resources and budget in the future.

One other opportunity here is that this executive could be in the position over time to establish a more formal center of gravity around open source in the company. These groups are typically called Open Source Program Offices (OSPOs) and generally are cross-functional groups supporting open source efforts across a company. Getting an executive involved early on in the first open source effort for a company helps give them visibility of the work done, and allows them to become a great ally in providing advice and guidance in evolving the effort into a program.

Setting expectations

Once you have this alignment, you are often set to go. However, to be successful, I’d recommend one more step, and that’s setting expectations.

With any effort, whether open sourcing code or any other business initiative, stakeholders such as those listed previously will have high hopes – and in some cases, they might be unrealistic. Maybe they think they will have 100 contributors in a month. Perhaps they think they will be the talk of Hacker News, or even that they will be able to scale back engineering efforts overnight. While sometimes you may get lucky with one of those, realistically, that’s not always the case.

When setting expectations, consider these dimensions:

• Time, both in terms of how long the process to open source code will be and also building up a contributor base. The former will be longer than you will likely expect if it’s the company's first time, as there will be a lot of legal review, in addition to the alignment of the stakeholders described in the previous section.
• Internal impact, as sometimes the code might not be as useful broadly as you think. Alternatively, the contributions won’t be very substantial for a while. Very few open source projects ever reach the Linux kernel or Kubernetes level; a vast number are small-scale, low-velocity projects that have value in their own right but may not be massive.
• Effort, and this is a big one, as people often have a mental image of “if we build it, they will come” with open source. Building communities takes time and is hard; we will dig into that more in later chapters.

Make sure your company and stakeholders don’t measure open source quarter by quarter, or else you will never see success. Do think of milestones along the way, but be careful of being too time-bound, as open source projects ebb and flow over time, and the company itself needs time to establish an internal culture. In future chapters, we will dig into project growth, scaling, and culture, and establish the base layer on which to build everything.

Hopefully, you now have the internal support for and alignment with open sourcing code for your company. Let’s take a look at a checklist of items for getting the code into open source.

Checklist for open sourcing a project or code base

If you are at this point, you have your company’s support for contributing to open source. Pat yourself on the back – what you have just done isn’t easy, and many before you never got to this point.

To actually make this happen, there are several key things you need to cover – let’s take a look.

Legal review

As the code that will be open sourced is effectively your company’s intellectual property, you need your legal team to review it before contributing to a project or launching a new open source project within one. There are also additional considerations for that code base that will come to mind for legal teams, such as the following:

• Is there any code licensed from a third party in the code to be contributed? If so, what rights does the company have to relicense and redistribute it?
• Does the company have any software patents that are implemented in the code base? If so, how comfortable is the company in providing other companies and individuals a license to that patent in the context of how it’s used in the project?
• What license is being used for the project, and will that enable the reuse of the project in the same way it’s used today (for example, if it’s part of a product, can the company redistribute the product with that code in it)?
• What contribution requirements are needed from a legal perspective? Do contributors need to provide a copyright license? Do contributors need to grant software patent licenses explicitly, or does the given license for the project cover this adequately?
• Are there other legal requirements the company will have to comply with for the license chosen? For example, if a company were to choose the GNU General Public License, there may be a case of needing to provide the source code for the parts of a product that could be considered derivative work.

With legal review, especially the first time a company is looking to contribute to open source or start a project, there is often a fair amount of education that needs to take place. Fortunately, there are some great minds in open source legal matters that will be helpful, which we shared in the previous chapter. Really, the main thing a company needs to decide from a legal perspective is how much risk is palatable given the opportunity. In other words, in open sourcing the code that a company owns, the company is in a sense giving its intellectual property to the world, but the question for a company is how valuable it is to them. Is it something that would bootstrap a competitor? Is it a big differentiator from other solutions? Is it a piece of code that isn’t super-unique to the company, and having it out there can create more value than holding onto it internally? This last question is one we see more and more in open source, as companies are realizing that while the piece of code could very well enable a competitor to bring a product to market faster, it lets the company itself seed the market with that technology and gives them a head-start before competitors can catch up.

One of the projects I worked with in the past, Zowe, wrestled with this. The companies who came together, Broadcom (then CA Technologies), IBM, and Rocket Software, all knew they had some really interesting code that they had built for revolutionizing the way we interacted with z/OS applications and data. They also all realized the pieces each of them had could be products of their own – and thus had good intellectual property value – but they came together and realized there was more value in the combined solution being open source so that they could focus on investments further up the stack in integrations with DevOps tooling, application monitoring, and deployment. That is the type of trade-off that comes from legal review, but more broadly from aligning the legal strategy with the overall company strategy.

Technical review

Finally, before you put any code out there, you need your technical teams to review it. There are a couple of parts to this:

• For one, the team should review it to make sure the code works. A project with code that can’t be used or is missing big pieces will wither from the get-go.
• Second, it should have documentation with it. It doesn’t need to be 100% fully documented from end to end, but enough that you can get up and running with the code, understand how it’s used, and navigate around the code base.
• Thirdly, scrub the code for any code or comments that might be tied to internal projects or tools that aren’t being open sourced. The prominent examples I see are comments with vulgarities, calling out employees by name, or mentioning IP addresses and passwords for internal servers.
• Finally, the code should be tested to help validate that it is working. In open source, people will take the code and modify it, so tests ensure that what is expected to work keeps working. It also is helpful with code that is compiled, such as C code, to ensure the binaries built are as expected.

One trap technical teams can fall into at this stage is “perfect is the enemy of the good.” I often talk with companies looking to open source code, and they tell me, “We need to build all our documentation, fix all the bugs, get 100% unit test coverage, and address any feature needs before we release it as open source.” I applaud that nobility, but at the same time, it can give a community the impression that the project is more of a product than a project, meaning comes off as finished work that doesn’t need any help or code contributions. Having a few loose ends in there – not any that would make the code non-functional but instead give space for someone to add to the code base or build it out – is a great opportunity to cultivate a contributor base. We will dig more into this topic in Chapter 6 and Chapter 9.

At this point, you should have a project out there or have donated code to a project, but how can you determine whether this has been valuable to your company? Let’s look more into measuring success for an organization.

Measuring success in open source to the organization

Success in open source is really hard to define. It’s not as straightforward as when building a product – in building a product, the success comes from the number of users or customers and the revenue from that, while in open source, usage is one part but so are the other potential impacts on the organization. Since open source projects tend not to be tied directly to revenue (after all, you are giving away code for free!), it becomes hard to succinctly define the Return on Investment (ROI).

But, there are some other ways to measure success. Let’s look at a few.

Setting (reasonable) goals

We touched on this earlier, but the open source project being launched or the work of the team contributing to an open source project should have certain goals. We talked about open source being a long-term versus short-term play, so goal planning has to have that in mind. But knowing how to show incremental progress is key to continuing to get the company to invest in the project, as well as for your benefit to know whether your project is on track.

Specific, Measurable, Achievable, Relevant, and Time-Bound (SMART) goals are a good framework for goal setting. This both helps you be clear on the expectations of the company and keeps you focused.

Here’s an example that could be used for the COBOL Programming Course example from earlier in the chapter:

• Within the first month, we will have our course fully uploaded to our GitHub repository, with all our governance and contribution guides in place.
• In 6 months, we will have 20 individuals who have completed the coursework.
• In 9 months, we will have 10 contributions not from the initial contributors to the course.
• By the end of the first year, we will have 5 regular contributors outside of our organization, and 40 individuals who have completed the coursework.

Two observations about these goals. First, they are focused on two metrics of success – contributions and usage. There isn’t a desire to get into GitHub clones or stars, issues opened, or the number of comments on a Hacker News post. This is a good thing, as the organization was sold on the concept of industry impact (more people learning COBOL when using more modern tools) and industry cooperation and alignment (having people contribute to one curriculum versus a bunch of other ones).

Second, they are goals that aren’t too much of a stretch; with enough awareness of the project, it won’t be too hard to hit these goals. It gives the project some breathing room to work through the kinks of launching an open source project, such as how to handle contributions, getting people used to the workflow, and keeping internal teams aligned with the community work. Not per se something trivial, and this helps set up the project for a better chance of success.

Identifying and showcasing how your organization is contributing

A big challenge that companies run into is how to recognize the impact, as, again, it’s not something that is tied to a tangible result such as revenue or customer counts as with commercial products and offerings. However, that doesn’t mean it’s impossible to get a sense of impact; in reality, an organization can use the motivations for open sourcing as a way to both measure progress and identify the wins and impact made.

Some things to consider for an organization here include the following:

• Adopting measurement tools that track multiple areas of contribution: For smaller projects, the GitHub community metrics might work well and integrate code commits, open issues, pull requests, and discussions. As a project grows, more complex tools such as Bitergia or LFX Insights will become useful; both will let you better associate contributions to an organization automatically and leverage a variety of data sources from different collaboration tools.
• Motivating your teams by tying open source contributions to annual goals or KPIs: This shifts contributing to open source from “do it when you have some time” to “this is part of my job, and I’m measured on it.” Be careful not to position this as a negative but as an opportunity, as nobody likes to be measured on something that feels like a chore.
• Developing internal recognition programs for open source contributions: This could be something as simple as an email to the team recognizing new contributors or top contributors during a certain period. It could also be an award for the most or most significant contributions in a period. In the early days of open source, I heard of one company that would give spot bonuses to anyone who merged code into the Linux kernel project; this motivated many to do so, though, from my understanding, the legal reviews one had to go through were so arduous that it often made it not worth those contributors' time relative to the bonus (but hey, it was a good try!).

The main point to consider with all this is aligning recognition to the goals the project aims to achieve. Recognizing the most issues closed might be a fun metric, but does that help achieve the goals of obtaining more users and greater industry adoption? As mentioned, when you have measurable goals, it makes it much easier to set rewards.

Summary

This chapter focused on many of the basics of a company going down the open source road the first time. Every major company that has been involved in open source has gone through this, and there is a fair amount of learning an organization has to go through to be successful with open source. Fortunately, there are great groups out there, such as the TODO Group, which is a group of leaders from OSPOs along many different verticals and horizontals, who can be resources for seeing how to be successful.

Getting an open source project off the ground is one thing, and indeed a feat to be proud of. But running one...that’s another fun challenge. In the next chapter, we will build from the launch of an open source project and learn about how to best govern it based on the community and industry you are working in.

Further reading

[1] Lessons Learned: IT’s Biggest Project Failures: https://www.pcworld.com/article/537052/it_project_failures.html