.jpeg)
(This is the seventh post in our Open Source At Large series.)
Open source is a powerful tool that offers great benefits to organizations that make, maintain, or deploy software. Most teams know they need open source capabilities. The hard part is finding a focus around adding skills. In most cases, the most important consideration is building capability to know how and when to use FOSS strategies.
FOSS is all about execution. Reaping the benefits of open source investment requires nailing a series of difficult steps ranging from designing an initial strategy to building an appropriate community to leveraging the resulting dynamics for strategic advantage. Many organizations are not prepared to travel that path and reap those rewards at scale. At OTS, we talk about that level of capability as organizational readiness, and we describe the journey to mastery as one of gaining capability.
To do that, we might locate a team in a readiness model. This clarifies where they are and also suggests next steps and likely results. Often, organizations use these models to identify areas for potential growth. We find the models are most useful for firms early in their open source journey, and this post focuses on those early stages.
There are several readiness models. OTS has for many years described climbing the readiness ladder (in various publications). Microsoft’s Jeff McAffer sees common patterns in an engagement model. GitHub also sketched maturity model as the start of a discussion on readiness. Similarly, Wikipedia reproduces an interesting model from Qalipso. There are a number of such models, and it is often worth considering more than one when examining an organization. Of the published models, we like McAffer’s in particular because it includes strategic components, accounts for realistic failure modes, and understands that open source readiness will be unevenly distributed in large organizations.
On many teams, initial open source capabilities might be nascent. Most team members have not had significant (or perhaps even any) experience using open source strategies to create value. The team works in an environment where FOSS investment is rare, and many do not see much reason to change that. That lack of knowledge might translate in some quarters into hostility toward FOSS. People will say “It can never work here” even as open source slowly seeps into more and more of the technology around them.
At this stage, FOSS strategies can be difficult to execute. Internal political risks might be high. Policies might explicitly forbid engaging FOSS. Staff doesn’t know how to begin to work with external open source teams. Many people will lack even a basic understanding of what it means to do open source work. Efforts to work in an open source mode are likely to fail in ways that reinforce the belief that open source is not worth further consideration.
Many factors might move an organization from hostility toward tolerating open source, but movement usually comes from external pressure, changing environments, and staff turnover. Conditions around the organization begin to change, and the costs and risks of refusing to engage start to rise.
Those costs might include the pain of maintaining internal forks of external open source projects (or, more precisely, the pain of not maintaining all those forks). Similarly, the benefits of making minor open source investments start to become clear, even if only from watching others make those investments and reap the benefits while your organization loses ground.
However organizations begin to come around, tolerating open source is all about experimentation. Firms usually don’t think of it in those terms. They are making small concessions to necessity. They are seizing unique, one-off advantages. Most don’t think of those small projects as the future direction of the company. They should consider the possibility, though. Sometimes, explicitly labeling such experiments as learning exercises and skill-building allows an organization to maximize the value of their experimental investment. It prioritizes reflective analysis and learning. It gives permission to fail. Those can be useful to companies seeking adaptability. When considering McAffer’s model, we might relabel his “tolerance” phase as “experimentation”.
Experiments come in many forms, but the most common first experiment is using some outside open source code and engaging the open source project. That might involve filing bug reports, offering a contribution, or merely participating in project mailing lists and forums. These are all relatively low-risk ways to begin connecting an organization to outside FOSS projects.
The experimentation phase is usually a skill-building and knowledge-gaining phase because it exercises the skills that cause an organization to shift from merely tolerating open source to trying to harness it. Having those skills provides the vision that starts to shift attitudes.
The problem that arises as companies start to embrace FOSS is that they lack the infrastructure to succeed at it across the entire organization. They are missing policies, auditing, skills, culture, and experience. This is a pivotal, risky moment. A large number of teams will still be in the denial phase. Efforts to move internal culture toward FOSS will be perceived by some as a pointless shift toward the latest buzzword. Those experimental skills will be unevenly distributed internally. Many new open source projects will fail, and this will convince some that FOSS is a failure. Some might even sabotage FOSS projects.
McAffer sees this phase as one of hype, and perhaps that’s because it’s also when an organization embraces open source without quite being ready to execute. Firms in this phase tend to engage FOSS in shallow, unsophisticated ways simply because they don’t yet have the experience to make better strategic use of open source opportunities. The way to move past this stage is not to reduce the hype (though that might help) but rather to increase readiness.
Managers at this stage — especially middle managers — need guidance on using FOSS as a strategic component and on managing teams with more external deliverables. Developers need technical infrastructure, easy-to-follow licensing policies, and permission to engage externally. Perhaps more importantly, they need to develop new habits of working in the open and sharing even early, rough versions of their work. Beyond just technical teams, Human Resources needs hiring and compensation guidance as both skills and performance evaluation criteria shift. Providing all of those pieces is the process of gaining proficiency. Adding skills, process, and policy is how that happens, and it requires management approval and resources. Companies that don’t provide this support from fairly high in the org chart tend to plateau at this level of readiness.
All of the above describes a path from the very beginning toward eventual mastery of open source. We think of readiness in terms of skills and capabilities, but the truth is that doing open source well is primarily a cultural shift. Organizations using open source fluently quickly find that the open approach becomes their default process. That culture shift will be the topic of a future post. For now, though, where is your organization on the path toward readiness? What are the steps you can take to help prepare for an increasingly open source tech landscape?