There are a lot of companies that rely on Free and Open Source Software (a.k.a, F/OSS) and adoption of their solution within various language communities. Often times, these companies are providing some kind of software or solution as a service and they're basically packaging up the existing F/OSS tooling and running it for companies or developers. Just as often, these are companies that give little if anything back to the projects and communities they rely on to survive.
As an example, let's look at the variety of companies that serve to provide test coverage and linting as a service so metrics can be measured over time. A few years back, there was an explosion of these services and generally speaking, each served the founders' preferred language communities and didn't provide a way to service others leading to the obvious result of each language having its own preferred two or three services. As a marketing and testing strategy, each of these companies offered their services for free to Open Source projects (and primarily they wanted to service GitHub users). [1] This services their marketing department because those users are going to evangelize their product to their coworkers and companies and start paying for it on their private repositires. It also helps them work out kinks because these folks are using it for free, finding edge cases and acting as unpaid beta testers and QA engineers.
Since then the landscape of this market has narrowed and some stronger contenders have risen to the top as they've grown support for multiple languages. Companies that arrived too late on the scene, couldn't raise capital, or didn't respond to their free QA testers didn't make it.
Supporting the Communities That Bring in Paying Customers
Now that we have some clearer leaders in the industry, you might think that these companies that are thriving in their initial market and expanding to new ones might start working on contributing back to the language and tooling communities that give them the ability to make all of their money.
Unfortunately, this is not what I've seen. In many cases, these companies instead decide to tell users to go out with their documentation and ask the language communities to integrate with them. Those users go to maintainers and other contributors and ask for their free labor. I think it's common for maintainers to view this as a reasonable request from a user to support one of these services. My brain usually reads this as "there's this layer of compatibility that must be created and it's easier for me to do this than someone else." The problem with this line of thinking is that these maintainers are not being paid to expand the markets for these companies.
We expand the potential market for a company and then see none of those profits. These are often the same companies that don't hire developer advocates or community members because they won't hire remote. So instead of hiring the best talent, they hire other folks in their preferred locations. In essence, I see a lot of maintainers being sucked into a terrible position. They want to ensure users are able to accrue the benefits of whatever tool they are maintaining. In my experience, the only result I've seen come out of this motivation is further strife, anger, and resentment if something breaks with that integration. The company will happily list "Hey we support X community with Y tools now!" and will not work to actively evangelize to all of those communities any up-coming changes. The end users often don't know what future changes might break the integrations they rely on and so are caught off-guard and often under some pressure of time.
These companies need to do more than publish their documentation of how to integrate with them and actively incentivize (through employment, cash, or something else) maintainers to work on these integrations. Perhaps, these companies could even hire folks to manage the integrations and maintain them after the initial authorship. Those engineers don't need to spend 100% of their time on the integration, but they could absolutely serve as the liaison to the community they serve.
An Example of How This Might Work
Full disclosure At the time of this writing, I work for Heroku but this model has worked excellently for years, and I'm not paid to write this nor are my opinions held by the company.
Heroku has what is commonly known as a "Language Owner". These are people whose job it is to work with the community and support developers and customers who use that language on our platform. They make sure the support for that language and its tools, frameworks, etc. are in tip-top shape and integrate with the community to ensure that the community benefits from a partnership with Heroku. Working on F/OSS is not the sole focus of the job. Evangelizing Heroku inside those communities is a small part of the job, but only in so much as making the experience as painless as possible. Contributing back to those communities as appropriate is encouraged and very important but these developers do product work inside the company as well that empowers them to do the community work they otherwise do.
Hiring engineers who are already familiar with a community can accrue so many benefits to these start-ups that I'm shocked to find out they don't have them. A company doesn't need to hire a personality or a well-known individual from that community to benefit from the hire. In many cases, just finding someone with the communication and empathy skills necessary is all you need. Find someone who can clearly articulate the mutual benefits of their contribution to their community and can help develop the integration. This person will not only help the F/OSS community improve but will almost certainly help your company improve. I haven't heard of a single language owner at Heroku who hasn't improved the company or its product in their tenure.
Often times, Heroku's language owners end up becoming well-known in the community just for being the public face of the company and helping people solve their issues. This ends up in a pattern that is:
- a win for the company by expanding their market,
- a win for the employee through improved reputation and unique experiences,
- a win for the community by having real-life best practices contributed back
Finally, your company may be too small to hire one person per community. That's fine, there are a lot of polyglots in the world who could spend the entirety of their time helping your company build up its profile in these communities. Find them, hire them, and let them improve your image full-time. Even if these developers can't provide the highest quality integration, if they create the base and empower a community to form and improve those integrations, you still win.
Summary
If you're building a service that integrates with several language communities, hire people who can help evangelize your product and improve the relationship with the community you sorely need to expand your market. The dividends on such a hire will pay off handsomely and in the end you will improve your marketshare.
Footnotes
| [1] | There's a perception that GitHub users are more likely to pay for a product than GitLab users and that so many companies already pay for private GitHub teams and repositories that this is the quickest way to a market. |