Makers, Users and Buyers of Open Source Software

Understanding your relationship to a project lets you ask the right questions.

More and more is being written about governance and license compliance and open source. The FUD of lawsuits continues unabated. Simon Phipps has an excellent post on trying to break out of the conversational frame that some use around compliance and governance.

One of the difficult problems is providing people a frame to understand which questions may be important for them to consider. In discussions several years ago, colleagues and I were trying to put together some form of open source maturity model so we could help clients understand where they were and what they needed to do next. We got caught wrestling with previous frames of reference like Golden’s OSMM and ideas like the Software Engineering Institute Capability Maturity Model. But it didn’t matter how we started the discussion, we rapidly realized there was no step that graduated to a next step. We all knew counter examples to any ordering we applied.

We had our epiphantastic moment when we stopped trying to order things on a spectrum of “growing” experience and instead treated open source participants based on what they were doing. It’s a Venn diagram, not a linear spectrum (or a two-axis quadrant). People fall into one of three groups with respect to what they do with open source:

• Makers actively develop free and open source software. They may be early in their participation and contributing bug fix code to a project, or they may be full blown committers in a community. They may be participating in someone else’s community, or building their own collaborative project. They make software. Makers relationship with open source is based on creation.
• Users actively consume open source software. As an end-user they install and run executable software. Whether they use subversion for version control, or Alfresco for document management, they consume without contributing and they aren’t particularly interested in the source code. As a software developer may they use libraries and frameworks, but if there’s consumption of source code it’s a side effect of the programming paradigm rather than a particular interest in the source code itself. Users relationship with open source is based on consumption.
• Buyers pay money for solutions. The practices are no different when an organization engages with Red Hat, Alfresco, or Microsoft. They are trading money to save time (buy versus build) and are purchasing a solution that includes more than “the software” regardless of whether the software is available under a free and open source license or not. Buyers are buying a solution and aren’t interested in the licensing of the software, except as it pertains to the solution they purchase.

Many people and organizations sit in more than one group. It’s a Venn diagram with overlapping circles.

If you think about the actions (make, use, buy) from a single software project’s community then Makers are clearly Users of the software in the communities in which they participate. If you think about the actions from a single organization’s perspective then a User of the open source software may also be a Buyer. There are situations where IT shops buy Red Hat servers for production, but work with Fedora or CentOS servers in development and test. A Maker of one project may be a User of a different project, and a Buyer of a solution in different place again.

The distinction of Make, Use and Buy, however, allows an organization to think about what are the right questions for things like governance and license compliance. As Simon points out, license compliance only becomes important if you’re distributing software, i.e. you’re a maker of something. Even then it’s very license dependent. Using the Make-Use-Buy idea as a positive framing, an organization can organize its relationship to open source projects based on appropriate activities. The centre for open source activities becomes a centre of knowledge to save time and money, rather than a policy centre to avoid improbable lawsuits through burdensome practices.

Imagine an intranet open source software resource centre that has a simple structure:

• Open Source Software We Use: List all the software in active use. For end-user software you could maintain a repository of current installable executables and the list of internal contacts for questions and support. If someone wants to add to the repository, they need to be willing to put their open source money where their mouth is and provide the contact name for whoever will handle the first line of questions and support and be willing to keep the binaries current. Keep case studies for internal uses and experiences based on money saved or much more importantly new value accomplished with the open source projects in use. There’s no governance or license compliance needed here.
• Open Source Software We Buy: List all the open source related software actively supported through purchasing and procurement, how to get binaries, and whom to call when it breaks. The only license compliance issues here are the ones any company selling software solutions puts in place and these have everything to do with enterprise agreements, EULA, and procurement -- not the open source licenses associated with the software. One more copy of a purchased Red Hat server isn’t much different than a purchased Windows server from a license compliance perspective.
• Open Source Software We Use in Development (and Make): This is the same as the Open Source Software We Use section of the resource centre, except for developers. It provides developers the extra level of consideration for licensing considerations if they’re going to start Making things that may end up being distributed to partners or customers. There needs to be a little more informational support in this part of the resource centre for internal tools and practices to ensure software experience is properly captured and shared. A repository of current releases and the internal contacts for initial support is as relevant here as it was in the Users section. This is where you let developers wanting to contribute back to external projects know what needs to be done. Most importantly, this is where you let your developers that are already active in external projects bring their expertise to work to save time and money and drive new solutions forward.
• Ensure the Open Source Software Resource Centre is searchable so it’s quick for anyone to quickly find out that “content management” software within the organization includes, for example, Drupal in the Use area and Alfresco in the Buy area.

Open source software as a re-use strategy (“use”, “share” and “borrow”) in conjunction with traditional “buy” versus “build” economics is a powerful strategy for solutions development in any organization. Understanding how one interacts with different projects and products adds clarity to the strategy and gives people the relevant guidance and framing they need when thinking about solutions. Frame the discussion right and it becomes a force for positive change.

• economics

• open source

• Software Development