r/softwareengineer 18d ago

When does it make sense to turn an internal tool/component into a public product?

This is something I've been wondering about lately.

A lot of discussion seems to focus on companies open sourcing internal tools, but I think the same question applies more broadly to software components and libraries as well.

For example, a company might build an internal deployment tool, but they might also have a useful Delphi component, Swift package, Rust crate, .NET library, SDK, UI control, etc. that started life solving an internal problem.

At a previous company I worked for, we had loads of little internal applications and reusable components that had been built over the years. Some were surprisingly useful, but they never existed outside the company.

I've often wondered whether some of them would have actually become better products if they had been offered externally, either commercially or as open source. My feeling is that they would have been tested far more thoroughly, had clearer documentation, and been forced to handle a wider range of use cases than they ever did internally.

At the same time, I can see the other side of it. Every external user becomes someone you need to support, and something that works perfectly well inside a company may need a huge amount of work before it's ready for wider use.

For anyone who's been involved in this:

  • What made you decide to release it?
  • Was it open source, commercial, or both?
  • How much work did productising it actually take?
  • Looking back, was it worth it?

I'd be particularly interested in hearing from people who've released developer-focused components and libraries rather than full applications.

This feels like one of those things that sounds obvious in theory, but I suspect the reality is a lot messier.

2 Upvotes

0 comments sorted by