Considering open sourcing software at your company?

From what I've seen in my career so far, the motivation to open source software at one's company tends to fall into one or more of the following buckets of reasons:

1) As a way of giving back to the wider software development community

Developers leverage so much open source software in their day-to-day work, and some see opportunities to open source software as a way of paying it forward and giving back to the community that has helped them throughout their career with free, well-maintained libraries, frameworks, and other tooling.

2) As a way of raising the standing of the engineering team at a company, and to serve as a draw for talented individuals that the company would like to hire

Having projects that are open sourced allows the company to say that they are giving back to the wider developer community on which a lot of their tech stack is highly likely built upon.

For talented individuals who are highly engaged in the wider software development community, especially through open source software, the opportunity to potentially work "in the open" is a draw to consider working at such a company.

However, before the leap is taken to open source code at a company, there are some considerations that should be thought about before doing so.

Maintenance

Once the project is released, what are the plans for maintaining it? Will there be resources (people, time, and money) invested in further developing the project?

If the plan is to release the project without further resources being invested in it, and the project is meant to be working software (not a collection of Markdown files outlining design patterns, ways of working, or a career ladder used within the organization, etc.), your company will want to make that abundantly clear in the main documentation of the project so as not to create the expectation from the wider community that the project will continue to grow after its initial release.

Admin work

If the plan is to maintain the project, then it needs to be viewed similar to other products/features the company makes available. And that leads to questions on who will be handling the administrative work.

Things like:

• Who will triaging issues that come in from the community?
• Writing documentation for others to be able to quickly get up and running with the project?
• Doing user research to understand if resources and time should be dedicated to extending the functionality of the project in a particular way?

Regarding that last point - tradeoffs often need to be made between what is asked for by the developer community engaging with and using the project, and what the long term goals of the project the company has in mind are.

This is a particularly important consideration if the company is running software built on top of this open source project.

Impact on being able to develop "big bets" within the project

Open sourcing a project means that it becomes much more challenging to develop new "big bets" - new features that indicate a direction that the company is moving in - within the project without publicizing it very early to the entire developer community, and therefore business competitors.

What ends up happening is that a fork of the project would need to be maintained in order to enable developers to build the "big bet", and then eventually do a "big bang merge" when it's ready for prime time.

This is a well-known anti-pattern in software development, but one of which there's not really a way around in this context.

Impact on dependency/vendor selection

If the open sourced project is being actively used within the company that made the project available, this limits the vendors/third-party dependencies that can be used within the project.

This is because, in order to allow the wider developer community to be able to run or self-host the open source project, these dependencies will also need to be open source.

And this means that, in instances where a proprietary service might've been better suited for the company's business needs, the company's hands are tied by their choice to open source their software, and limiting their options on what they can do in this respect.

Impact on company reputation

I mentioned earlier that one of the motivating reasons for open sourcing software can be to improve a company's reputation as a place where there's a strong engineering culture, with talented individuals working to improve and give back to the wider software development community through open source.

However, this blade can cut both ways.

If the correct functioning of the software being open sourced is tied to proprietary systems, resulting in developers having to perform a lot of workarounds in order to use or deploy the project for their own uses, it can (and will) feel like a bait-and-switch.

Additional, even if the above is not the case, if it's not made clear about what is happening with a project in terms of how it will be maintained, if at all, it can lead to mismatched expectations and result in a negative, rather that positive, impact on the company's public image within the software development community.

Wrapping up

These points to consider are not meant to scare folks off from open sourcing software, but to highlight considerations of open sourcing projects that some don't realize until they're dealing with these challenges.

Open sourcing a project is a wonderful way of engaging with the wider software development community. It can lead to many positive outcomes for that project including new, creative ideas for features and fixes for bugs that the maintaining team may otherwise have not noticed or caught.

Speaking from first-hand experience, working "in the open" was an incredibly rewarding experience and made me a much better software engineer, and I hope that more people get the opportunities in their careers to do so.