Open source mistakes for enterprise newcomers

Open source increasingly touches every corner of the technology industry. Virtually all tech companies now use open source in their products, many participate in external open source projects, and increasingly companies are starting new open source projects to serve business goals. Everywhere we look, we see more open source and deeper involvement.

We also see a lot of misconceptions and missed opportunities.

This does not mean open source efforts are failing. Code gets written, and products ship. But often companies don’t get all the benefits they could from open source, and are not fully aware of the choices and tradeoffs they are making.

Open source is more than just a license and a public GitHub repository. When done with commitment and understanding, it has broad implications across one’s entire business. Below are some of the patterns we’ve seen across scores of companies, as they start exploring open source software as an active practice. When done well, open source can lead to better communication across your company, new modes of engaging customers and even competitors, improved engineering quality and responsiveness, and access to a broad talent pool. But these advantages are best realized when the entire organization is involved and committed. When open source is treated as a checkbox to be checked, or as just one feature of many added to a product, then it becomes merely a layer of bureaucratic overhead, resented by engineers and their managers alike.

Open source is a path, not a destination

Open source reinvents relationships and business dynamics, turning customers and even competitors into collaborators. Firms embrace it to encourage those dynamics, when the benefits of participating outweigh the gains from going it alone with proprietary code. But open source isn’t an outcome in itself. It is an approach for finding where different firms’ interests intersect and helping them cooperate there — but it is the path, not the place. To enjoy its full benefits, one must visibly walk that path.

Companies are often tempted to skip to the end of the path. They want to develop software in secret and then flip a switch at the end to ship a fully-realized product that comes with a nifty feature: “Now with more open source!” This rarely works. For a whole host of reasons, the resulting project is unlikely to bring most of the benefits that open source is capable of bringing. The code may be freely licensed and the repository public, but even if the product is a hit, wider participation will not magically appear, because potential participants will see that no open source process is in place.

A company must go through the long process of building a developer community, inviting collaboration with other stakeholders, and working across corporate and project boundaries — and that process only starts once the code is opened. In short, the company must walk the path. It can start that walking at any point, but it can’t skip to the end.

Open source earlier than you’re comfortable with

Waiting until the end to flip the open source switch has another business disadvantage: it gives up momentum and first-mover advantage.

While your developers toil in secret, hiding behind their NDAs, some of your competitors are out there building coalitions, cooperating, and investing together. By the time you start investing in an open source process, you are competing against their dynamics instead of the other way around.

Companies usually have three worries about releasing code as open source early. The first is that it may harm their development process, because it can involve an adjustment of development methodology or habits. The second is that it could give up a potential information advantage: knowing that you’re planning to open source something could itself be a competitive advantage that should not be given up lightly. The third is embarrassment: “Our code isn’t ready yet! Our programmers aren’t comfortable letting other people see it until they’ve had more time to pay down all the technical debt.”

None of these worries is ridiculous. Let’s take the first two first:

Open source may well require some adjustment to development methods, and it’s true that signaling your plans provides your competitors with some information. There are occasionally circumstances where one or both of these concerns should legitimately govern the timing of when you make a project public.

But such circumstances are rarer than you might think. If your teams are going to need to adjust their working methods anyway, it’s usually better to start sooner rather than later. Learning how to integrate open source practices in the early stages of a project can be tricky, but newcomers to open source are better off navigating this tricky terrain early. Later in the development cycle, deadlines are more pressing and closed-source habits have already solidified.

As for sending signals about business strategy, keep two things in mind. First, much of your overall strategy is fairly obvious to your competitors anyway, just from the nature of your business. Second, if competitors change their behavior based on seeing you start an open source project, this is as likely to work in your favor as against it. To the extent that your initiative matters to them, they have, in a way, willingly placed you in a leadership role relative to their own planning. Instead of hiding, use open source to take full advantage of that role.

As for embarrassment or a feeling that the code isn’t ready for outsiders to see yet: Just Do It. Really, the earlier you open source, the less of a concern this should be, because everyone knows that no code base starts out looking perfect. But you can open source at any point without embarrassment: the fact that virtually everyone has this concern about their code is the sign that none of them need to. Insecurity is never a good strategic motivation.

Middle management is where open source becomes organizational culture

Open source usually comes to a company either top-down or bottom-up.

Sometimes, a company-wide strategic vision drives the turn toward open source: upper leadership recognizes the benefits of open source, and then makes broad changes to foster changes wherever it might improve the company’s position. Other times, the software engineers drive a move toward open source, because they see first-hand where it will help their work. In the latter case, open source activity may happen under the radar, or developers may openly advocate for it with their managers, but either way the driving energy is coming from the leaf nodes — from the engineers, not from some grand strategy.

Either way, middle management has the most influence over whether the benefits of open source are realized.

Middle management is the conduit that carries messages about shifting problems and priorities. When those shifts involve a move toward open source development, the organization can think and act productively only if managers recognize what’s happening. Middle managers are where open source is internalized; if they are not on board, the organization will fail to capitalize fully on the benefits of open source.

To give just one example, many firms must reconsider evaluation and compensation when they shift toward open source. As staff spend more time taking part in open source projects, it can be difficult to know how to weigh their accomplishments at evaluation time. If managers are too focused on the budget and deliverables that are within their immediate purview, they may undervalue their team’s open source work, which can include advocacy, educating other developers, reviewing contributed code, and other things not normally within an organization’s reward structure. A developer paid from a specific business unit might contribute to open source in ways that spread benefit throughout the firm, yet her manager might be tempted to pare away the open source work, because getting more of the developer’s time focused on the business unit’s immediate goals will feel like a win, even if it is a loss for the company overall.

Another example is that one of the most interesting benefits of open source activity is that it often improves internal communications at a company. Developers start working with people in other business units, with whom they might never have collaborated were it not for their common participation in the same open source project. These connections are naturally most effective when managers on both sides are aware of and support the collaboration.

Open source succeeds best when officially supported from the middle out, not just from the top or the bottom of the organizational hierarchy.

Expect resistance to organic culture change

Open source eventually has transformational effects not only in your code, but in your org chart and non-technical policies as well. If managers and HR teams refuse to let these transformations spread through the company, they relinquish both the technical benefits of open source collaboration and its potential improvements to corporate culture.

When experienced open source developers work together, they do so in recognizable patterns. They expect a certain set of widely-used collaboration tools (version control repositories, bug trackers, automated testing systems, and so on), and they will tend to use those tools in conventional ways that are common across many different projects. This is true even for tasks far remove from software code: writers and editors will work on a document in much the same way as a development team works on code, using the same conventions and customs to coordinate their work and make decisions. The open source collaboration toolkit is not just the technical collaborative infrastructure, it encompasses all that process as well.

Staff who are habituated to open source collaboration will naturally push for similar dynamics in other aspects of their work. The drive to share by default, and to leave doors open wherever possible, becomes ingrained. For example, how an organization observes ownership of tasks often changes under the influence of open source’s skepticism about formal boundaries.

Hiring and HR also tend to shift as open source ascends in a company. Good open source candidates leave tangible proof of their value when they collaborate outside the company. They leave this proof in public places, in front of a whole community of stakeholders looking for expertise. Open source creates job opportunities for your best hires at the same time that it exposes your company to a vast new hiring pool. Managing that and other HR changes often requires fresh approaches.

Open source development thus puts pressure on the non-engineering parts of a firm to change. Not recognizing that need, or not meeting it well, is a normal challenge for firms new to open source.

The community can’t replace your developers

Sometimes firms see open source as a way to get cheap development resources. They look at their open source investment, translate that to a headcount, and weigh lines of code in the submit queue versus what an in-house developer might have produced. They dream of the day when “the community” is ramped up and they can reassign the firm’s developers to other projects. This day never comes.

Open source contributions will provide real value, and may even substitute for some of your own development work. But they won’t decrease your development investment. Your developers work on your priorities and are accountable to you; the value of that is high, and no company should give that up.

When an open source project succeeds, it becomes more valuable to your company in proportion to how it becomes more valuable to its community as a whole. You might reach the point where core development is shared across multiple companies, but your own organization’s developer investment will likely stay the same or even increase. A project succeeding at that level should spur greater investment, not less.

At some point, you might ramp down investment in the project, but that is because conditions have made the project less valuable to you, not because you are suddenly getting the same value as before for free. A good rule of thumb is that your open source investment remains proportional to your benefit, whatever the size of the larger community.

In a nutshell

As your business uses and contributes to open source projects, remember that open source is a path. Walk it visibly, and involve middle management from the start. Take the lessons of open source and apply them across your processes, not just to development. The path doesn’t have a final destination; rather, continued investment as you follow this strategy yields continued returns. An open source strategy forgives the occasional misstep as long as you keep walking.

---

This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.