When I tell people that I work at an open source consulting company, I often get puzzled glances (or those agreeable nods that mean “I have no idea what you’re talking about”). What does “open source consulting company” mean? What does OTS do, exactly?
Who are we?
At Open Tech Strategies we do open source development and process consulting for corporations, government agencies, and non-profits who want to produce or use open source software more effectively.
Okay, but what does that mean?
Why open source?
Formally, “open source” just means software code released under a free license. But publishing code that way often turns out to have very powerful effects, so a more useful way to think of open source is as a way of aligning your organization’s goals and its production processes. When you are trying to extend the life or the applicability domain of a software project, improve transparency and accountability in your organization, collaborate more effectively with partners or volunteers, increase user engagement with a service, promote user privacy, or grow a vendor ecosystem, open source provides a ready-made set of practices and promises that enable your natural allies to find & join you in the effort.
Open sourcing a project doesn’t necessarily mean giving up control, except insofar as you decide that that doing so better serves your goals, but it makes it possible for a project to grow beyond the interest or budget of just one organization; we’ll look at some examples of that in later blog posts. And building on open source software means that organizations don’t need to pay to re-invent technological wheels like content management or databases and can focus on their own specific needs.
(See also Ben Balter’s excellent post “Why open source” for a more in-depth look at why organizations choose open source.)
So that’s open source. What exactly does OTS do, though?
Usually, I describe our work as falling into one of a few different situations: building, opening, and buying.
Example Client #1: Builder
This first example client, Builder, needs a piece of software to complete their mission work. They might be a non-profit fighting homelessness or youth violence or a corporation that needs a new research tool. Builder decides to use an open source custom-built solution for reasons of cost-effectiveness, transparency, or one of the other points I mentioned above. Over the course of an agile development process, we meet with the end users of the product and involve them in testing as soon as there’s anything to test at all. All of our development takes place in the open, and we maintain install documentation so that anyone could set up a sandbox instance of the project to try out. When this process is done, Builder has a working piece of software in production that can be set up and maintained by any software development team using our open code and documentation. Their partners can set up the same system, extend it, and share any enhancements they make with Builder. We often continue to work with the customer beyond this point, of course, but the software’s “developer surface area” is now much greater than it would have been were it proprietary: both we and Builder have the ability to welcome new partners into the project, and being able to exercise that ability has proven quite useful.
Example Client #2: Opener
Another kind of client, Opener, comes to us with an existing software product. Possible Openers are a data visualization and outreach engine for astronomers or a transparency tool for governments. While the software product is not the entirety of Opener’s mission, it is a crucial part of the work and face of the organization. For Opener, we focus on code resiliency, partner collaboration, contributor engagement, and (where applicable) development of a commercial ecosystem around the project. When we complete our work with Opener, they have a usably open source project that has clearly-documented code, findable discussion forums on the web, an issue tracker in use, and all the other affordances of a well-arranged open source project. The project is well-positioned to invite new collaborators and engage users.
Example Client #3: Buyer
A third type of client can be called Buyer. This client is an organization that wants to use and/or contribute to open source software, but needs advice on adapting their procurement processes and on how to invest strategically in software technology. Buyer might be a government agency that needs to set up definitions and standards around procuring and using open source software, or could be a foundation or corporation that wants to invest in open source but needs some advice on how to select and support the right projects. For Buyer, OTS researches the state of the field in their area of interest and provides recommendations for investment and/or procurement routes. When we complete our work with Buyer, we often deliver a highly specific report on the best ways they can use or invest in OSS. They are prepared to interact with open source in the way that best advances their strategic goals.
That’s the story (mostly).
Naturally, not everything we do falls neatly into these categories of building, opening, and buying open source software. For example, we also offer advice for companies that want their employees to be able to contribute to upstream open source projects and helps open source projects draft CLAs or think through their business strategies. If you’re a Builder, Opener, or Buyer or just have questions, feel free to reach out. Thanks for reading!