The problem with Amazon and Open Source isn’t Amazon

Wrong Way
‘Wrong Way’ by Elaine with Grey Cats on Flickr; CC-BY

Recently a friend wrote asking me “what’s up with Amazon and open source?” and “is there a chance these new licenses will be approved by OSI?” What follows is my reply.

There’s been a rash of open source project relicensing happening the past few months, and in nearly every case the company making the licensing change is claiming that that they’re doing it to protect the project in question from Amazon.

That is a big steaming pile of bullshit.

First of all: There is absolutely nothing wrong with how Amazon is using these open source projects. They are operating completely and entirely within the bounds of the licenses of the projects. Fingers need to be wagged here, but not at Amazon.

These projects are not being relicensed to protect them from Amazon. Claiming that they are is at best naive and at worst wilfully lying. These companies are relicensing projects to cover for the fact that they are ignorant of how to run a successful business. They knowingly released their secret sauce under permissive licenses and have discovered that doing so means that competitors can create more compelling product offerings based upon the same technology. This is entirely in accordance not only with the licenses that these companies knowingly chose, but also with a competitive market. The only problem with this is that it came as a surprise to these “open source” companies and now they’re reacting poorly.

If these companies actually cared about the projects, they would have invested the resources to build stronger communities around them. They would have reached out to Amazon, encouraged them to contribute back to the projects, and helped them to do so. They would NOT have taken the few community contributions—and you will find that most of these projects do not have many contributions from outside of the originating company, showing how poorly they managed their communities—they would not have taken these contributions from community members and then locked them behind proprietary licenses, violating the trust of their community.

You will find that none of the companies that have relicensed their projects address any of these issues. They don’t discuss how they tried to engage Amazon in their communities, how their attempts fell on deaf ears or were rebuffed. They can’t do this because thus far there is no evidence to show they even tried. I know a lot of the open source leadership at Amazon. They’re good people who care deeply about free and open source and who are working to do the right thing by all of the communities of the projects they build upon. They would have been very open to hearing how they could make a positive difference in those communities. They’re a relatively few people across a very large company, so it may have taken a bit more time to get those contribution balls rolling, but they would have worked very hard to do so…had they been approached.

So don’t fall into the trap of unquestionably believing the recent spate of anti-Amazon propaganda. It comes from, without exception, companies that simply do not appear to understand how to operate successful businesses. From what I can tell, they’ve received poor advice from their VCs. Not knowing any better, they understandably followed this advice and now they’re paying the price.

As far as whether there’s any chance these new licenses will be OSI approved, I answer a pretty definitive “no.” There are two reasons for this. First of all, these companies would have to submit the licenses for review. OSI does not just go looking for licenses to review. License creators must take the action to say, “Hey, this is a new license that we believe adheres to the Open Source Definition. It’s valuable to us and to the community that it be recognised as such. Could you please review it and confirm that?” So far only one company has tried that and they failed to get their license approved, because of the second reason…

In order to become OSI-approved, licenses must adhere to the Open Source Definition (OSD). These new licenses do not. While the ways they diverge from the OSD are varied, the most common ones are that they violate either “6. No Discrimination Against Fields of Endeavor”, “8. License Must Not Be Specific to a Product”, “9. License Must Not Restrict Other Software”, or “10. License Must Be Technology-Neutral”.

#6 is the one most violated by these licenses. Restricting to non-commercial usage is fundamentally against the spirit of free and open source software. From the very beginning, Stallman himself was very emphatic that people be allowed to make money from free software. He and FOSS leaders after him realised that preventing people from making money from free and open source software will doom the movement. It is vitally important to FOSS that people be encouraged to use it in commercial and for-profit ventures. This will help foster the spread of FOSS. These licenses disregard both that and the benefit of this clause of the OSD to the whole of FOSS in preference to their own singular commercial needs.

In fact, the vibrant cloud-based and cloud-native environment within which most software companies operate now and which makes so much innovation possible (including that of these misled companies), exists because companies have released their technologies under OSI-approved licenses and have come together to collaborate on common and powerful tools. This is the culture that successful companies embrace. Even Microsoft, the former nemesis of free and open source, recognizes that this type of collaboration is critical to the continued growth and evolution of the company.

To be perfectly clear: There is nothing wrong with making money from software, FOSS or otherwise. Choosing to use a proprietary license for software is a valid business decision and one I support. Choosing to use an OSI-approved license is an equally valid business decision and, again, one I support. However the license to choose for the software created by your company is just that: a BUSINESS decision.

There are many potential variables to consider and those variables will be different for each company, but “how will we make enough money from this to maintain and grow the company sustainably?” is one that is consistent across all of these decisions. If a company’s answer to that is, “we’ll just give away the software to bring in leads” but they don’t have a compelling enough commercial offering on top of that to convert those leads to sales, while their competitor converts those leads and more using the same technology, that is NOT the fault of open source software, licensing, or culture. That’s a company that doesn’t understand how to do business, and blaming Amazon isn’t going to change that.

Commons Clause is a Legal Minefield and a Very Bad Idea

Image from page 256 of Bugle-echoes : a collection of the poetry of the civil war, northern and southern (1890)

I recently received a question from Christine Cardoza, journalist at SD Times:

I am writing a story on all the controversy in the industry going on with the Common Clause license. I know it is not an OSI approved license, but I was wondering if you had a statement you could provide on this. Some of the sources I have talked to say they do believe this still promotes open source and that the OSI needs to change some of its rules, so I would really love to include OSI’s take on this if possible.

Her article will be out soon, but she gave me permission to publish my response now:

Hi, Christine. I believe there were plans for OSI to make an official statement on this kerfuffle, but I don’t know where that is in the process. What follows is my professional opinion as an open source strategy and policy consultant for businesses and should not be construed as an official OSI statement.

First of all, terminology: Commons Clause is not a license. It’s a clause that can be applied to licenses. Specifically, it’s intended to be applied to OSI-approved licenses. By restricting people from making money from a project where it is applied, the Commons Clause directly violates Item 6 in the Open Source Definition. As the Open Source Definition is no longer applicable to those projects, they—quite literally by definition—are no longer open source. At best they can be called “source available.”

The Commons Clause FAQ states that “[t]he Commons Clause was intended, in practice, to have virtually no effect other than force a negotiation with those who take predatory commercial advantage of open source development,” however at no point have I seen a statement from either the Commons Clause creators nor any project(s) applying it that they attempted other approaches to encourage collaboration from those they see to be taking “predatory commercial advantage” of their projects. For instance, Redis recently applied the Clause to a few of their modules due to “…today’s cloud providers…taking advantage of successful open source projects and repackaging them into competitive, proprietary service offerings.” Their statement on the change does not say, “We approached the cloud providers and asked them to collaborate, but they refused,” or even “We approached the cloud providers and asked why they do not collaborate and how we can improve this experience for them.” From the outside looking in, it does not appear as though Redis tried to encourage collaboration before throwing a tantrum and relicensing to this proprietary license. That’s not how to be a good free and open source citizen.

As far as that is concerned, their stated reason (“taking advantage of open source projects”) does not square with their actions, as instead of relicensing the project (Redis) that is being taken advantage of it relicensed a few modules instead. While this could be seen as them testing the waters prior to a large relicensing of the main project, the core developer has stated that this will never happen. Therefore it does not seem as though the relicensing will gain Redis much beyond some major damage to their reputation. It feels as though they—an open core company—looked at that open core, decided it was a little too large and they could be a stronger business by shrinking it by a few modules. That’s a completely valid business decision which I would not fault, but it’s not the stated reason for the relicensing. The entire situation is quite perplexing.

And then there’s the Commons Clause itself. Heather Meeker helped to write it. She’s no fool and is a very accomplished and well-respected intellectual property lawyer who has a career of experience working with free and open source licenses. Despite this skilled help, the Commons Clause team came up with a restriction against selling that is so broadly stated that it puts an impressive number of people at risk of license violation should they come into professional contact with any project that is under a license tainted by the Commons Clause:

“…practicing any or all of the rights granted to you under the License to provide to third parties, for a fee or other consideration (including without limitation fees for hosting or consulting/ support services related to the Software), a product or service whose value derives, entirely or substantially, from the functionality of the Software…”

According to this restriction, I as a freelancer would violate the license if I helped a client who used Redis and happened to use one of these modules with the tainted proprietary license. I would probably be held liable even if I were unaware of the use of those modules. I’m far from the only freelancer who looked on the Commons Clause with horror. For instance, Jim Salter, a freelance system administrator, network specialist, and author, says he now feels he can’t work on any project that involves Redis lest he put himself at risk. He’s only one of many freelancers I’ve heard express these thoughts and state outright that they will not work on projects involving Redis. They simply can’t afford to lose their livelihoods due to a legally vague license.

As to the question that open source needs to change, I’ll simply direct you to my blog post on the subject and summarise it as: Open source does not need to change; people simply need to learn how to do business. Stop using open source and expecting it to do the hard work of creating a successful business. It’s a tool, and it’s a great one, but it’s only a tool.

Open source is NOT a business model (and your business will fail if you think that it is)

Southern Pacific Sunset Limited Diner, Budd Company, from SMU Collections, Flickr

Consider this conversation:

Person 1: Did you know that 60% of restaurants close within three years of opening?

Person 2: Oh no! We should change the fundamental definition of “food”. That will fix it.

How does that sound to you? Ridiculous? Good, because it is. Now compare this conversation:

Person 1: Did you know that a lot of “open source” companies can’t make money?

Person 2: Oh no! We should change the fundamental definition of “open source”. That will fix it.

This conversation is just as ridiculous, yet I’ve seen many versions of it recently. Some misguided souls are saying that the Open Source Definition must be changed to include matters of revenue and profit (AKA “how to make money from open source”), because open source is a business model. Let’s just get this settled once and for all, OK?


According to Harvard Business Review, it’s difficult to define ‘business model’. Some of the definitions they’ve collected over the years are:

  • “All it really meant was how you planned to make money.”
  • “…assumptions about what a company gets paid for…”
  • “…a good business model answers…How do we make money in this business?”

There is a great number of potential business models, but “open source” is not one of them. It is, instead, one of the many tools that can be employed in order to make a selected business model work as expected. The most common form of employment here for open source is in open core, which is itself just a variation on the freemium model. In this model, the open source is the tool that is used to entice potential customers to come to the company and hopefully to hand over their money for additional features or advanced support.

Going back to the restaurant example above, saying that open source is a business model is like saying “food is a business model.” Both are things that can attract potential customers, but each is just one of the tools that get customers there. Usability, suitability (market fit), advertising, good service, open source… Each of these is among the many elements that can help convert a prospect into a customer, and each is employed differently depending upon the market and business model.

Therefore open source has not, does not, and should not concern itself with business any more than food concerns itself with business. If there is a business that has a business model that is not living up to expectations, and if that business model uses open source as one if its tools, it’s illogical to blame open source for the failure. That business is asking the tool to do all of the work, rather than learning how to use the tool effectively.

The best way to have a successful business is not to rely on trendy business models and buzzwords. It’s to learn and practice business administration, to learn what the customer needs and values, and then to find a business model that will deliver that value while also supporting the profitability of the enterprise. For some companies, that business model may be open core, but it’s worth researching the past performance of open core companies before taking that plunge.

In 2015 John Mark Walker published a series of articles on under the title, How to Make Money from Open Source Platforms. In the first article of the series, he makes the astute observation that no successful product has come from an open core company. The rest of the series investigates other business models that companies can explore related to open source products and projects. He shows how it’s possible to make money and build a successful business around free and open source software, but that success is due to savvy business acumen and not necessarily due to the free and open source software itself.

So, please, take more care when selecting a business model for your company, and please stop thinking that open source itself is anything more than a tool to help execute that business model.

Redis Labs and the Questionable Business Decision

Redis Enterprise is Everywhere
A screenshot from the Redis Labs website, taken 2018-08-21.

I’ve been trying to take a bit of a break from writing, but considering what I do for a living, how I spend my free time, and the baffling level of WTAF of today’s news, taking a break from break-taking seemed in order.

Today Redis Labs announced that it was adding something called the Commons Clause “…to certain components of open source Redis.” It acknowledges that this means those components are no longer open source, but hand waves that away and implies that it’s not a big deal.

It’s a big deal, and it’s a bad idea.

The Commons Clause is intended as an add-on to OSI-approved licenses. Its primary purpose is to remove “the right to Sell the Software.” Unfortunately, it goes on to define selling as:

…practicing any or all of the rights granted to you under the License to provide to third parties, for a fee or other consideration (including without limitation fees for hosting or consulting/ support services related to the Software), a product or service whose value derives, entirely or substantially, from the functionality of the Software.

Which, you know, is monumentally vague and won’t at all cause problems in court, now will it? Yes, it will. Despite that, the Redis Labs legal and executive teams decided to go forward with this relicensing. What did they hope to accomplish?

Did they hope to force Amazon and other big corporations to stop eating the Redis Labs lunch? If so, they’re going to fail. What will happen is that Amazon, probably in conjunction with Google, will fork Redis to avoid this problem. While it could continue using and developing this fork internally, it’s more likely that they’ll release the fork as a FOSS project, thereby wooing away the existing Redis community and contributors. This will allow them to continue operating as they already are without having to bear the entire burden of maintaining the newly forked project. Redis Labs, on the other hand, will be left with the entire burden of maintaining the original Redis project.

But maybe the problem was that Redis Labs was already carrying this entire burden. Their statement does, after all, include this line that implies this may be the case:

Redis Labs is leading and financing the development of open source Redis and deserves to enjoy the fruits of these efforts.

A review of the Redis project contributions (which I have not done) would reveal whether this is what’s happened. If it is, then there are better ways to play nicely in the free/open source playground than to take your ball and go home when someone does something you don’t like. For instance, you could evaluate why there are so few other contributors to the project and then take action to improve those numbers. Or you could approach the biggest users directly and ask them why they aren’t collaborating more, then cooperate with them to help encourage contributions. Or, if you’re relicensing everything anyway, you could switch to something like the AGPL, which would cause other enterprises either to release their own source code or stop using Redis. Of course, this would probably just lead to a fork as mentioned above, but at least Redis Labs would come out looking like a shrewd member of the FOSS community rather than a foot-stamping child.

The entire situation is just perplexing. This sort of change undoubtedly had to receive approval from a lot of very smart people at Redis Labs, and that approval undoubtedly happened after many hours of discussions and emails. Despite that, they decided to go forward with this unfavourable change. If I were one of the investors in Redis Labs, I’d be raising a skeptical eyebrow and taking a good hard look at just what in the heck is going on over there. Questionable decisions like this shouldn’t be able to get through so many layers of leadership without being shot down.

Anyway, you can look forward to a bevy of thinkpieces from free and open source software luminaries in the next few days, all doing the same sort of finger wagging and WTFing that I am. None of us think this is a good idea, which is to be expected from our ilk and is not really news. What interests me now is seeing how the rest of the market reacts. What will AWS, Google Cloud, and the others do with this news? And how will this affect the revenues and profits of Redis Labs? Will they be able to keep up their streak of 10 quarters so far of double-digit growth?

Let’s find out.

FOSS as a Part of a Corporate Sustainability Plan

Article originally published in the May 2018 issue of Linux Journal

Free and open source software is a critical part of your company’s supply chain. Here’s why and how you can include it in your corporate sustainability plan.

In 1983 the United Nations convened a commission of 22 people to investigate the question of the worldwide environmental and social impact of human development. Four years later, in 1987, the commission released Our Common Future, more commonly known as the Brundtland Report in honour of Gro Harlem Brundtland, chairperson of the commission. This report detailed the very real socio-environmental issues facing humanity. One of its recommendations was for governments, organisations, and companies to start engaging in what it called sustainable development. That is, “…development that meets the needs of the present without compromising the ability of future generations to meet their own needs.”

Since then there’s been steep growth in the number of corporations that maintain and operate according to a corporate sustainability plan. These plans encompass environmental as well as social aspects of doing business. They encompass actions within an organisation—such as natural resource usage, diversity and inclusion, and fair treatment of employees—as well as those external to the organisation—such as the sustainability operations of their entire supply chain as well as the overall impact the corporation has on the Earth and its inhabitants.

The benefits of sustainability

A sustainability plan impacts every facet of an organisation’s operations and can take a fair bit of effort to implement and maintain. If that’s the case, then why are more corporations putting these plans into action every year? While it would be nice to think that this occurs for entirely altruistic reasons—taking care of the Earth and its inhabitants is simply the right thing to do, after all—the fact of the matter is that studies repeatedly show that properly implemented corporate sustainability plans are very good for the bottom line.

Innovations and profitability

Sustainability requires partnering and collaborating not only across groups within the organisation, but also with many external to it. These collaborations expose a corporation to new ideas and innovations in market, process, policy, and product, all of which can lead to improved profitability while moving the company toward its sustainabiity goals. Without the support and engagement of all employees, a sustainability plan will fail. Therefore the execution of a sustainability strategy requires a shift in management from the old style of command and control toward a modern style of trust, communication, and employee development. By empowering and training employees, a sustainable corporation improves its ability to execute plans while also increasing employee satisfaction and retention. Beyond just innovations, profitability is increased through reduced expenditures, entry into new markets, and a lower cost of capital.


Investments are also impacted, as more investors are now looking at a corporation’s sustainability plan as a deciding factor on where to place their money. When you think about it, it’s surprising that sustainability hasn’t been a primary investor consideration before now. The strategies that support a successful corporate sustainability plan, focusing on what’s good for society and the environment, are also those that do good for the company. Protecting the organisation’s value and supply chains enables it to ensure it will be around for a good, long while. That longevity—and plan to maintain it—is very appealing to investors in search of both stability and a positive return on their investments. Despite this, studies show that most high level corporate managers still don’t recognise the importance sustainability holds for investors. This provides a great opportunity for those managers who can launch and make a corporate sustainability plan successful before their competitors.

So, yes, corporate sustainability planning (when done properly) is that proverbial rising tide that floats all boats. However, for companies that rely upon technology to keep their business operating (read: all of them), there’s a major component that’s usually left out of their sustainability plan: the software.

Open source software is a part of your supply chain

Operating systems, databases, libraries, infrastructure management and orchestration… No matter what component, all software is a part of your company’s supply chain. How much do you know about it? Do you know what your company’s software supply chain looks like? How much of that chain is or depends upon free and open source software? If you haven’t investigated this before, you’ll likely be surprised by the answer. If you look at little deeper, you’ll be even more surprised to discover just how few people maintain and support the software on which your company relies to operate and do business.

However you look at it, this arrangement is fraught with sustainability concerns. Socially, allowing so few people to perform so much work for so little compensation is inappropriate and does not scale. From a business perspective, it’s very poor practice to rely upon suppliers who may burn out and disappear at any moment. This does nothing good for the longevity prospects for your organisation and dramatically inceases its risk profile.

Open source software is good for sustainability

Don’t get the wrong idea: I’m not here to spread Fear, Uncertainty, and Doubt (aka FUD) about having free and open source software projects as a part of your supply chain. Even a quick glance will show that you’re unlikely to receive as much value and flexibility from proprietary solutions (if they even exist). Proprietary software is incredibly expensive, less flexible, leads to vendor lock-in, and is at least as likely to disappear without notice. 90% of software startups fail, taking their products and their code with them. The high cost, low innovation, and equal risk of mortality for proprietary software makes it a less appealing solution when considering the longevity and sustainability of your own company. Free and open source solutions are simply the better option.

What is YOUR software supply chain?

The answer, then, is not to cut out the free and open source links in your supply chain. No, the actual answer is to include free and open source software in your corporate sustainability plan. Unlike proprietary software, free and open source (FOSS) solutions enable your company to take action to ensure that the FOSS projects themselves are sustainable. So, how can your company do that?

For starters, if you haven’t done so yet, take this opportunity to become very familiar with your company’s software supply chain. Certain links in that chain will be more important and more strategic than others. While your software sustainability efforts should include all of the links in the chain—FOSS or proprietary—you may find that it makes sense to focus more of your investment in these strategic links.

Build a culture of contribution

As you’re evaluating and integrating your software supply chain into your corporate sustainabilty plan, start communicating internally about the importance of this supply chain. This communication should be across the entire organisation, not simply constrained to the technical departments. By communicating and including the entire company, you open up more avenues for ideas and innovations in sustainability as well as start to build a culture of sharing and contribution that will aid in all your sustainability efforts, FOSS or otherwise.

That culture of contribution will be critical for the next step: empowering staff members to contribute back to the FOSS projects on which your company relies. Reporting bugs and requesting features is one way to contribute, but fixing bugs, adding features, and contributing those changes upstream to the main project is what will lead to improved project longevity. It often can make sense for a company to pay team members to work full time maintaining and enhancing strategic free and open source software projects, but even small contributions submitted by individuals scattered across the organisation can aggregate into a large amount of work toward sustaining projects on which your company relies. Making it easy for team members to contribute will make it much more likely that they will support the projects through their contributions. Remember, too, that FOSS projects need more than just programmers in order to thrive. Enabling contributions from your QA, design, marketing, and other departments will enhance the entire ecosystem of the free and open source software that enables your company to operate, adding to its longevity and reducing risk both for it and for your own company.

Share the load

As you review your software supply chain, consider the problem that each one of those links in the chain is there to solve. Your company is not the only one to have those problems. These are issues faced by many organisations, and no one company will be able to solve these shared problems.

Therefore the next step in integrating free and open source software into your corporate sustainability planning is to release the software your company has developed to solve problems shared by others. Of course this doesn’t mean you should necessarily release the software that provides legitimate market differentiation and value for your company, but there are undoubtedly several tools developed internally that are not of strategic market value but that solve specific problems. By releasing these tools, you enable collaboration with organisations that share similar problems.

By working together to solve these problems through free and open source software, all collaborators share the load of development. This allows them to benefit from the tool while also freeing up internal resources to focus on strategic value creation for their markets. In a case study created by Open Tech Strategies and released by the World Bank, collaboration on free and open source software tools led to a 200% return on investment for the collaborators. Sharing the burden of maintaining these tools ensures their longevity and stability while reducing institutional risk. The end result is a more sustainable business and a healtier free and open source software ecosystem.

Join a Foundation

Depending upon the free and open source software in your supply chain, one approach toward sustainability may be participating in the organisations and foundations formed to support projects that are strategic to your company. By joining organisations like Open Source Initiative, Eclipse Foundation, Apache Software Foundation, and the Linux Foundation, your organisation not only has a seat at the table when discussing the future of strategic FOSS projects, it also gets the opportunity to meet, discuss, and collaborate with companies it may not have had occasion to interact with otherwise. By bringing together disparate organisations and providing not only a shared purpose but also a safe environment for collaboration, these foundations enable member companies to learn from each other and to open the doors for new partnerships and innovations.

Think strategically

I’ve said it already in this article but it’s worth repeating that, just as with the rest of your corporate sustainability plan, it’s crucial that your company’s approach to supporting free and open source software projects be strategic. While it’s tempting to contribute to all FOSS projects equally—and certainly the projects themselves would not complain—from a sustainability point of view your organisation should try to focus its resources on those projects that make a material difference to your company. Material difference means that a project, were it to stop being developed or maintained, would severely impact the operations of your company. These are the FOSS projects most directly linked to your organisation’s longevity, and also makes them risk factors for your corporate sustainability plan.

In order to determine which projects are material to your corporation, you must be fully aware of your software supply chain. This involves not only looking at the free and open source software that allows your company to operate, but also digging deeper to learn on what projects those projects rely. It’s all well and good to acknowledge that the authentication library used for your product is material to company longevity, but if that library itself relies upon cryptographic functionality in another—woefully under-funded—project, your company may be exposed to unforeseen but preventable risks. Ignorance of your software supply chain is no defense against vulnerabilities. Cultivating an awareness of the entire ecosystem within which strategic and material FOSS projects operate will help secure corporate longevity and sustainability.

Make a business case

Focusing software sustainability efforts on material and strategic concerns makes it considerably easier to incorporate free and open source software into the business case for your company’s corporate sustainability plan. It may be tempting to skip this step, but if you do so studies show that it’s likely your sustainability plan will fail. When you pause to consider this, it makes perfect sense. Why should a corporation invest so many resources in shifting the way it does business, up to and including its very business model, if there is nothing in it for them? Again, setting aside altruistic appeals and the fact that taking care of the Earth and its inhabitants is just the right thing to do, being able to make a well-researched and detailed case that doing so is good for the bottom line makes it more likely that even the less environmentally- and socially-minded leaders in your company will get on board with the plan. Don’t simply list what changes will be necessary to enact a corporate sustainability plan, but also reveal exactly what is in it for the company for making this effort.

You’re all in this together

As mentioned earlier, it’s important for any corporate sustainability plan to create a culture of contribution across the entire organisation. If upper management does not communicate what the plan is meant to accomplish and why, it will fail to get the support of the employees who actually have to do the heavy lifting of implementing that plan. Without the support of the entire organisation, your corporate sustainability plan will fail. Sustainability must be a 360 degree effort, not simply something dictated from on high. All members and stakeholders of the company must understand what the sustainability plan is, what impact it will have, what part they specifically will play, and how they will make a difference to the overall outcome.

This communication is hard enough when the plan is simply about environmental and social concerns, issues with which most people are familiar, but it becomes much more difficult when unfamiliar concepts like “free software” and “open source” enter the mix. This is why it’s so important to begin the discussion as early as possible. It can take some time for people to understand that “contribute back to free and open source software projects” can be as meaningful and impactful to the corporate sustainability plan as “reduce water usage,” “use energy from renewable sources,” or “eliminate the gender/race pay gap.”

To help with this communication, rather than dictating implementation details to middle management, company leaders should instead set software sustainability goals for each team or department and then allow each group to define how it can best contribute toward those goals. For technical departments their contributions may be as straightforward as providing patches or releasing internal tools, while less technical departments may come up with less obvious approaches to helping the effort. By empowering each team to approach the problem in its own way, the company is not only encouraging innovation but it’s also building trust within its ranks. This trust, as mentioned before, increases the effectiveness not only of the sustainability plan but also of other operations undertaken by these teams. This trust also leads to higher employee satisfaction and retention. The overall culture of the company evolves into one that is more collaborative, innovative, and therefore sustainable.

Keep yourself accountable

A vital part of any corporate sustainability plan is the company holding itself accountable for delivering on its promises to itself, to its stakeholders, and to the communities on which it relies. Fostering a culture of collaboration includes supporting open communication. That openness must permeate all levels of the company. Embracing and supporting free and open source software and their underlying values can help to cultivate the communication required for accountability. Instituting inner sourcing is a good way to encourage collaboration, communication, and cross-functional accountability on your corporate sustainability plan.

Accountability can also be included at an organisational level by way of performance reviews. For this to work, each employee must understand how they contribute to the overall corporate sustainability plan so that they can work toward meeting their particular goals. This is especially important at the executive level. When leaders are held accountable for their sustainability strategies and plans, it reinforces the importance of the effort to the organisation and encourages participation by all members. Reporting on the company’s progress on its sustainability plan also provides accountability to external stakeholders like investors, partners, and customers. For many companies, it can be uncomfortable at first to embrace this form of open communication both internally and externally, but if they are able to make this shift they’ll reap the benefits of sustainability. It can be a difficult journey, but it’s one entirely worth taking.

Do I have to use a free/open source license?

Article originally published in the March 2018 issue of Linux Journal

Man thinking at a deskA few weeks ago I ran into a neighbor, whom I’ll call Leo, while he was out taking his dogs to the park. Leo stopped me to ask about some software he’s developing.

“Hey, you do open source stuff for companies, right?” Leo asked.

“Yeah, that’s my freelance business. Do you need some help with something?”

“Well,” he said, “I’m getting ready to release my software and it’s time to start thinking about a license. Which open source license should I use if I want people to know it’s OK to use my software but if they make money from it they have to pay me?”

I blinked, stared at Leo for a moment, then answered, “None of them. No open source licenses allow for that.”

“No, you see,” he continued, “this guy told me that there must be plenty of licenses that will let me do this with my software.”

“Plenty of proprietary licenses, maybe,” I explained, “but no open source ones. According to Item 6 in the Open Source Definition, no open source license may prevent someone from making money from software released under it. That’s what you’re suggesting, and it’s not possible to do with an open source license.”

Leo did not seem pleased with this answer. “So what you’re saying,” he fretted, “is that I can’t release my software at all!”

“No, no!” I assured him, “You definitely can release and distribute your software. You’ll just have to get an intellectual property lawyer to help you write the proprietary license you want, and maybe to help you release it under a dual license (one open source and one proprietary).”

He nodded (not altogether happily), and headed off to the park with his now very impatient dogs. I continued my walk, pondering what I’d just experienced.

The thing is, Leo was not the first person I’ve spoken to who assumed that software had to be released under an open source license. I’ve had multiple conversations with different people, all of whom had mentally equated “software license” with “open source license.”

It’s easy to understand why. Of all software pursuits, only free and open source software is defined purely in terms of its licenses. Without that license, a piece of software cannot be either free or open. This leads to a greater focus on licensing than for other types of software, which then itself gains a lot of mindshare. The larger intellectual property concept of “licensing” becomes so closely associated with “open source,” and is often the only context in which someone hears of licensing, that people understandably start to assume that all licenses must therefore be open source.

That, as we all probably already know, is not the case. The only licenses that can be called “open source” are those that are reviewed and approved as such by the Open Source Initiative (aka OSI). Its list of OSI-Approved licenses allows developers to choose and apply a license without having to hire a lawyer. It also means that companies no longer need to have their own lawyers review every single license in every piece of software they use. Can you imagine how expensive it would be if every company needed to do this? Aside from the legal costs, the duplication of effort alone would lead to millions of dollars in lost productivity. While the OSI’s other outreach and advocacy efforts are important, there’s no doubt that their license approval process is a service that provides an outsized amount of value for developers and companies alike.

OSI approves or rejects licenses as qualifying as “open source” by comparing them to the Open Source Definition. A license must not violate any of the sections of the definition in order to be added to the list of approved (and therefore open source) licenses. Aside from the, “you can’t prevent people from making money from it” precept mentioned above, other requirements contained in the Open Source Definition include non-descrimination (you may not prevent certain people or groups from using your software), that the license be technology neutral, and of course the requirements of the Four Freedoms as originally defined by the Free Software Foundation. If you haven’t read the Open Source Definition before (or not for many years), I encourage you to do it again now. It’s an important and powerful work that is the foundation for much of how many of us spend our days.

It’s worth stressing again that no license can be called an “open source” license if it does not adhere to the Open Source Definition. Full stop. No exceptions. It’s illogical to think that something that doesn’t meet the official definition of open source could ever legitimately be called open source. Yet people try it every day mostly because they, like Leo, don’t know any better. Thankfully, there’s an easy way to fix this. It’s called Education.

Basically, you only have to choose from two different types of licenses:

  1. Free and open source: If you agree that the software you want to release should obey the Open Source Definition, then you should select one of the OSI-approved open source licenses from the list they provide. You may still need an IP lawyer to help you make the correct license selection, but you’ll need considerably less of their time than if you weren’t to use one of those licenses.
  2. Proprietary (and likely custom): If there are any parts of the Open Source Definition that you don’t want to apply to the software you want to release, then you’ll still need a license but it will have to be a proprietary one likely custom-written for your purposes. This absolutely requires an IP lawyer. Where licenses are concerned, you should never roll your own. Copyright and licensing are very complex legal issues that you should in no way undertake on your own without professional assistance. Doing so puts yourself, your software, and your organisation at risk of large legal problems.

To be clear here: There is nothing wrong with using a proprietary license for the software that keeps the lights on at your company (figuratively speaking). While I, personally, would prefer everything be free and open, I also prefer that companies remain solvent. To do that, it’s usually necessary for some software to remain proprietary, if only for a while. It’s bordering on business malpractice to release the “secret sauce” of your company’s product offering without a business model that will allow the company to remain or become profitable. Once your company has established itself and is secure in its market, only then should it consider releasing its mission-critical software under an open source license (and I do hope it does do so).

Companies like Amazon and Google can release critical infrastructure as open source because they no longer really compete on product, they compete by having scaled to a point that no newcomer to their product spaces could possibly replicate. If tomorrow Amazon were to release the software for S3 under the GPLv3, it’s unlikely it would at all impact their profitability. The number of companies that could take this code and spin up and scale their own product offering with it and do so in a way that could compete with Amazon’s existing dominance and scale? Vanishingly small, and those that could do it are unlikely to be interested in doing such a thing anyway (or already have their own solutions).

With open source as with all technical and business decisions: Do not do something simply because the big players do it. Unless your company has the advantages of scale of an Amazon or a Google, please be very careful about open sourcing the technology that pays the bills. Instead, hire a good intellectual property lawyer and have them write you a proprietary license for the critical software that you distribute.

Entering the Free and Open Source emerging market

Originally published on

In business speak, an “emerging market” is a market that is not yet well developed but on the rise and shows strong potential to be as robust as other developed markets. The Wikipedia definition focuses purely on countries, but this is a limited view of the meaning of “market.”

Whether a market is developed or emerging depends entirely on the product or service being offered and the receptiveness and awareness of a market to that product or service. For instance, Italy would not qualify as an emerging market by the Wikipedia definition. Yet, with an Internet penetration of only 58.5% of the country, it could be considered one for broadband Internet providers.

By this more inclusive definition, free and open source software (FOSS) is an emerging market for most of the corporate and business world. It’s a new land, abundant in resources and promise, and businesses are getting very excited about the possibilities. It’s also an entirely foreign culture, and many businesses are struggling to learn how to operate in this new land.

A new land

The place where business meets an emerging market is a liminal zone, which is space that is neither here (standard business practice) nor there (Wild West mentality), and where transformations are more likely to occur. In literature and mythology, all of the most exciting things occur in liminal zones. Operations in a liminal space, such as the meeting of an emerging market and a business, are not as constrained by a “business as usual” mentality; therefore, they are free to explore new solutions. The meeting of diverse approaches and philosophies can lead to incredible innovation in processes and products. With such potential, a growing number of businesses are looking to enter the FOSS emerging market, which is no surprise.

Entering a market is entering into a relationship, and like all relationships there is more than one perspective to consider. According to a study published in the MIT Sloan Management Review, this is where many organizations fail when attempting to enter emerging markets. Being very familiar with and confident in “how things are done,” organizations enter emerging markets with a business-as-usual attitude. They fail to do the necessary market research and don’t learn enough about the culture, the market needs, or even the communication norms and language. Unsurprisingly, their efforts lead to disappointment and a withdrawal from the market, usually to the benefit of local competitors.

This business-as-usual approach leads to expectation mismatch. Businesses expect that their usual go-to-market strategies will gain them entry, their usual processes will get things done, their usual messaging will gain them positive attention and brand recognition, and their usual language is appropriate for all communication. Some companies entering a FOSS community or project expect to mold them to their needs through force of numbers, either human or financial. This works about as well as you’d imagine. Companies expect Step 3: Profit will follow. Disappointed by unmet expectations, businesses decide that FOSS will never work for them. They withdraw from participation in FOSS and leave that emerging market to their competitors.

When businesses are unable to participate in FOSS, doors close for everyone. It deprives companies of the benefits of FOSS participation, including faster development and innovation, more efficient recruiting, word-of-mouth marketing, and lower total cost of ownership. The community or project becomes deprived of the benefits of corporate support, such as wages for maintainers, support for essential infrastructure, and sponsorship of events and participants.

How to step foot onto new land

As businesses set foot on the foreign land of FOSS participation, they should take care to treat it as they would any emerging market: with the respect and consideration due an unfamiliar culture. Businesses should tailor their entry to the market and not engage the autopilot to business as usual. Taking the time to pause, reflect, research, and listen can pay remarkable dividends and better ensure success. Part of this reflection should be confirming that the FOSS organization knows what it wants to get out of the relationship, and ensuring that this is a mutually beneficial arrangement. As with entering any new endeavor, you can reduce the time required to ramp up the team by hiring someone already familiar with this emerging market and its pitfalls.

While those of us on the management and business side of things learn how we enter the emerging market of FOSS, there’s no reason FOSS communities, projects, and supporters can’t do a little to help out our end. As with any relationship, meeting in the middle is the best way. For a successful entry into this emerging market, a business must learn the FOSS language, culture, and needs. The FOSS community can do its part to help a business do this, perhaps even by reaching out and offering to teach them. This may be one of the best approaches, because it also allows the FOSS community the opportunity to learn the language, culture, and needs of the business, making all communication more efficient and successful.

Most importantly, the FOSS community must try to be patient, non-judgmental, and empathetic when businesses inevitably stumble. Many people still retain an old-fashioned perception of emerging markets as savage or unsophisticated, although this is a view that has no place in technology or in business. The same can be said of business’ perceptions of FOSS. Many still see free and open source projects and practitioners as dogmatic, phlegmatic, and anarchic. Assisting businesses to enter the FOSS emerging market and picking them up should they fall will go a long way toward dispelling these misconceptions and we will all reap the benefits of broadening the scope of our collaborations.

Avoid failure when supporting free and open source communities

Originally published on

This is Part 3 in a series of articles three on community management best practices. Read Part 1, Practical business reasons to support open source communities, and Part 2, How your company can build and keep community trust.

Although supporting a community offers many benefits to an organization, to imply that there are no risks to the organization or community manager would be disingenuous. When handled poorly, engaging with a community can lead to major growing pains, raging headaches, and total meltdowns. In this article, I’ll discuss how to prevent the headaches before they happen.

If your organization decides to invest in and grow a community, not knowing why you are supporting a community and what results you expect are a huge problem. Humans—some more than others—are social creatures, so the appeal of being part of a community can be strong. However, that does not excuse your organization from responsible business practices. Undertaking any sort of large initiative without understanding the business reasons for doing so, or criteria and metrics for success, is irresponsible and not sustainable.

Defining ROI

Still, many organizations dive head first into community (and other) initiatives without having done basic due diligence from a business perspective. They fund the salaries of the community management team and sponsor community events without discussing assumptions, expectations, parameters, metrics, or anticipated ROI from the endeavor. Down the road, this inevitably leads to awkward conversations. And some of these conversations negatively impact the community, which can lead to serious blow-back and negative PR for the organization.

Another risk organizations face when initiating a community support program is mistaking the community for a market or for customers. Although community members may also fit these roles, and traditional marketing and sales outreach techniques can be helpful at times, treating the community like anything other than a community can lead to resentment and ill-will from its members. Remember: A community is a self-organized and self-identified collection of people. Identification is a powerful thing, and treating someone contrary to their selected identification is arrogant and disrespectful. When an organization begins to think of the community as merely a well-qualified market or as sales leads, it has lost connection with the community and risks losing members and public negative feedback.

Community value

Organizations that do not think through business aspects of their community support programs risk devaluing the community they support. Without considering the business case for supporting a community, the organization can fall into thinking that any community will do, and that this community is expendable or hot-swappable for another that the organization can simply support or build in parallel. Again, this line of thinking ignores community self-organization and identification. It dehumanizes the community members, treating them as interchangeable cogs turning in a machine cranked by the organization. This dehumanization creates a blind spot in the organization such that they are surprised when the community exercises its agency and independence, often with unfortunate results for the organization.

Organizations that decide to support a community and then, through neglect, allow the community to fall into disrepair are also at risk. Communities will self-manage; there is no requirement for an organization to swoop in and offer its support on that front. But a self-managing community is not always a healthy community. Through neglect, indifference, or political skulduggery a community can become a negative space that is unwelcoming to the new, the reasonable, the empathetic.

An organization that reneges on its promise to help manage and lead a community cannot walk away from the reputation it earns by being associated with a negative and toxic community environment. This is, of course, a worst-case scenario. More often, a community left in neglect withers and dies silently. But sometimes thriving and toxic weeds overrun it, and ignoring this possibility is a mistake that a supporting organization makes at its own peril.

Then there is the problem of expectations mismatch. The organization cannot simply decide to support a community, go stomping in there waving money and touting their principles, and then expect to be embraced as a conquering hero. Entering a community, as I mentioned in Part 2, takes time and deliberate effort. A large part of that effort is communicating why the organization has decided to become a part of the community, what they hope to gain, what the community will gain, and how the organization intends to operate both within and outside the community.

Communication is key. Both sides must openly outline expectations, otherwise they risk an expectations mismatch, which can sour the community to future support from the organization. If the organization supports and listens to a skillful community manager who understands the community and its members, the chance of an expectation mismatch goes down. The communication pipeline provided by the community manager ensures that all sides understand what is going on, when, why, and how everyone can contribute.

Enter the community manager

I’ve discussed the benefits and risks to organizations supporting communities, but there’s another piece of the equation that is often overlooked: risks to the community managers themselves.

Community manager (or a variant, such as developer relations) is a relatively new job title in the tech industry. As organizations began to recognize benefits of supporting a community, they also began to see the need to have one or more employees guiding, growing, and communicating with that community. But problems with this role can start early on, when organizations aren’t clear on expectations and requirements for measuring the community manager’s success.

Community managers are in curious and occasionally awkward positions. To succeed at their jobs, they must participate in their communities at a level that can appear to be disloyal to an employer and in favor of the community. In fact, a successful community manager plays the role of diplomat and translator between organization and community, representing the organization’s interests within the community, while transmitting the feedback and concerns of the community back to the organization. The community manager must understand the perspectives and motivations of each side and work to balance and achieve goals to benefit both.

This is a difficult task in the best of situations, but becomes particularly challenging when the organization misunderstands the diplomatic role of the community manager, and instead expects them to enforce organizational edicts without regard to effects on the community. This can be perceived as disloyalty to the organization rather than what it is: the community manager working to protect the reputation of the organization.

Community manager ROI

Community managers also have the challenge of proving their value to their organizations. The metrics required for such validation often are difficult to track, nebulous, or both. Proving the ROI of a community support program is hard enough; proving the impact of an individual community manager on that ROI is even more difficult. For the sake of community managers and of the community program, that organizations define metrics and criteria for success before beginning the undertaking is vital.

Community managers who are not armed with metrics and organizational expectations are unable to show the value they bring to an organization, and they become low-hanging fruit when budgets are cut, and they can be cut out of the picture. Often organizations that choose this option are those that failed to outline their motivations and expectations for supporting a community. And, having not thought things through from the start, these organizations rarely have considered the repercussions that losing a community manager can have on the community and how it views the organization.

Other risks to community managers are more personal in nature. For instance, embedding oneself within a single community can lead to difficult career mobility. Becoming a trusted member of a community takes a great deal of time, energy, and emotional investment, and although the relationships built and interpersonal skills learned are valuable and transferable, a community manager cannot simply jump from one community to another as easily as a programmer can move from one project to another. When an organization decides not to continue supporting a community, or if the community manager is no longer satisfied with their role or organization, finding a new position can be difficult.

How your company can build and keep community trust

Originally published on

This is Part 2 in a series of articles on community management best practices. Read Part 1: Practical business reasons to support open source communities.

If you are part of an organization looking to get into the community-support game, you would do well to tread carefully and deliberately. Communities, particularly at the start of your involvement in them, can be delicate and fragile things. Stomping in there with big words and big plans and big brand engagement will cause a lot of damage to the community and its ecosystem, often of the irreparable sort.

Before your organization sets forth on the community path, take the time to do research first. Learn who the members of the community are, and about the social dynamics between them. Learn the community’s jargon, but not in a “How do you do, fellow kids” sort of way. Listen to what the community members discuss, what concerns them, what they enjoy, what they’d like to change. A week or two of research can help prevent many otherwise non-obvious missteps once you start engaging with and participating in the community.

Once you finally do take the plunge into community support, being open and sincere about both your intentions and the role you will be playing in the community is vital. As this is a community coalesced around a project or product on which you rely, the community likely will welcome a representative from your organization into the fold. But dissembling and pretending not to be associated with the organization will inevitably be discovered and will cause ill-will on the part of the community members.

First build trust

When supporting a community, initially building trust in the members of that community is important. Without trust, you will never be able to guide, direct, or grow a community. It will not matter that the community formed around one of your organization’s projects or products. If community members do not trust you, you will not be allowed to participate in the community and you will lose all of the business benefits of that. Furthermore, the community may turn from your product/project entirely.

The actions that build trust within a community are the same ones that build trust between any people or organizations:

  • First listen. Listen, listen, listen. Listen more than you speak. The community has things to say and wants to be heard. Take the time to listen carefully.
  • Then speak. When you do speak, do so to make promises based upon what you have heard. Making the promises is not nearly enough; you also must deliver on them. If you’re not making promises when you speak, you should be asking for feedback and input and then, again, taking action upon this.

Community communication

Another important reason for you to speak rather than listen is the unfortunate situation of negative interactions and experiences within the community. If not for the sake of the community, then for the sake of your organization’s reputation, you must maintain a policy of zero tolerance of abuse.

When speaking with the community, you must always be open, sincere, and honest, brutally so if necessary. Part of this may include owning up to your mistakes, communicating what went wrong (and what’s being done to correct it), and making sure it never happens again. This is more than just PR; it’s building, reinforcing, and validating the trust and relationship you’ve established with the community.

This level of listening, delivering, and communication can form a strong foundation of trust that will get your organization and the community through both good times and bad. When both sides trust and support each other, that’s when the real magic begins to happen. Furthermore, that’s when other people, viewing the community from the outside, start seeing that magic and want to be a part of it. A strong, vibrant, and trusting community practically builds itself. All it needs it an understanding hand to help guide it and to keep the negative influences and personalities—which find their way into every community—from taking root.

That guidance, and building and maintaining trust, can be a full-time job. Organizational interaction with a community requires a lot of hands-on, high-touch, intimate and open work, otherwise community trust is lost, and community members will turn away from the project/product and the organization. This work is the purview of specialists, people who have invested the time and effort to become intellectually and emotionally familiar with and to the community. These are people who become trusted members of the community and work for the organization as advocates for the community to help provide maximum benefits to both sides of the equation. These people are often called community managers, despite the fact that most of the management that they have to do is upward and internal to their organization, rather than within the community.

A good community manager is knowledgeable of and trusted by the community, so little management is required on that front. What is more often the case is that the organization for which they work does not fully understand the complexities and benefits of the work that the community manager is performing and will—intentionally or not— obstruct or attempt to control the community. This puts the community manager in a difficult position, where they are forced to explain diplomatically the counter-productive actions of the organization to a perplexed community, while also trying to explain the benefits (at risk of being lost) of community support to an organization that may not have thought such things through prior to establishing a community support program.

Stay tuned for the third and final article in this series, coming next week.

Enjoy this post? There’s a lot more where this came from. Hire me to help your company be successful with Free and Open Source software & communities.

Practical business reasons to support open source communities

Originally published on

Recently I’ve had several conversations with open source friends and colleagues, each discussion touching upon—but not directly focused on—the subject of why a company would/should/could support a community around a project it has released as free/open source, or more generally to support the communities of F/LOSS projects on which they rely. After the third one of these conversations I’d had in nearly as many weeks, I dusted off my freelance business consulting hat and started mapping out some of the business reasons why an organisation might consider supporting communities.

In this post, I’ll look at community from a business perspective, including the effect community can have on an organisation’s bottom line. Although there are communities everywhere, I’ll approach the topic—meaning, communities, their members, and their contributors—from a free/open source perspective. So please stick around, and maybe you’ll learn ways to communicate the importance of community to your organisation.

(Also, be sure to check out my list of 16 resources for measuring open source community ROI.)

What we mean when we talk about community

First, let me explain what I mean by community. A community is a self-organized collection of people sharing a concern or interest. Although it’s possible to build, grow, and manage a community, this concept of self-organisation is important for providing and maintaining the vibrancy that comes with a strong community. Strong communities are composed of people who self-identify as members of the community, not those who are assigned or forced into it. Members may join or leave the community at will. The members of a community retain complete agency as to their initial and continued membership.

Why would a person become a member of a community? Some will drop in to acquire help for a problem they’re having, but merely dropping in does not necessarily mean a person identifies as a member of the community. Those who return, however, have at least started this self-identification process. Something they experienced on their initial visit convinced them that this is a group with which they’d like to continue to associate. Perhaps they return because of the social dynamics. Perhaps it’s for the shared affinities and inspiring conversations. Perhaps it’s for the friendships they are building. Whatever the reason, a community is similar to so many other things in life: First impressions matter. A community environment in which people do not feel heard, do not feel appreciated, and do not feel comfortable leads to the erosion of the trust and bonds that allow a community to thrive, in addition to increased ill-will toward those who ostensibly claim management over the community.

Communities, fundamentally, are people. Typically the community “personality” is an amalgam of the personalities of the most prominent members. Thus, if the personality skews too far toward the negative, the community will develop a reputation as being negative and unhealthy. One role community manager(s) play is to help shape and guide the community’s personality to build an environment that helps the community members meet their goals, and that benefits organisations that support it.

Business benefits

Why, though, would an organisation invest resources in supporting and guiding a community? How does community-building help the bottom line?

Measuring the ROI of community is tricky, but really no trickier than any other outbound communication effort your organisation attempts. If you’ve ever tried measuring the impact of your organisation’s PR, outreach, branding, and advertising efforts, you know how difficult a task this can be. However, just because something is difficult doesn’t mean it’s not worth doing. Although measuring community support success is challenging, supporting a vibrant community can provide many benefits, both quantifiably and otherwise.

A strong, engaged community gains your organisation the holy grail of marketers everywhere: word of mouth marketing. The community you support will become your street team, spreading word of your organisation and its projects to anyone who will listen. Additionally, an engaged community will provide the most on-time and in-depth market and competitive research. Community members become not only your staunchest defenders, but also a ready, willing, forthright, and cost-effective focus group when the organisation needs to try out new ideas. When you’re out of new ideas, your community will be there as a resource to provide you with the inspiration and experience necessary to spark and potentially implement well-targeted and brilliant innovation, while also pointing you to new tools and best practices to bring that innovation to life more quickly. When that innovation does take off and your organisation is looking to expand, the community it has supported provides a rich and passionate pool from which to recruit new team members, dramatically reducing the time and resources required not only to fill open positions, but also for onboarding once hired.

If word of mouth marketing, market research, product focus groups, and a technical talent pool aren’t enough for your organisation, there are myriad other business benefits to supporting a vibrant community. For example, community members, having been involved in technical development, will likely be early adopters of your latest technology or solutions. The support community members provide each other not only leads to lower support costs for your organisation, it can also lead to lower cost of ownership for the community and those who rely upon it for assistance. And if something does go wrong with your product, for example, an engaged community can provide higher goodwill, tolerance of errors, and public support and PR in times of crisis. Of course, this community support for your organisation only lasts as long as your organisation remains supportive of the community. The moment members of your community sense your organisation is being disingenuous—and they will sense it, on that you can rely—they will rightfully drop support for your organisation, and possibly expose it and all of its flaws.

When considering the benefits of supporting a community, and the metrics for determining success, it’s important to remember that most of these benefits require playing the long game. Trust is not earned overnight, and without the trust of the community, your organisation is unlikely to reap the benefits of supporting and being a part of that community. Most discussions about metrics should be phrased in the context of months and years, rather than days and weeks. Give your program adequate time to get off the ground and start showing results before using those metrics to determine whether the effort is successful.

Enjoy this post? There’s a lot more where this came from. Hire me to help your company be successful with Free and Open Source software & communities.