Ask HN: As a startup, should you open source your internal tools? | Hacker News Reader

Ask HN: As a startup, should you open source your internal tools?

5 pointsgfarah4 comments

On my startup (fintech), our team has built a couple of tools/frameworks for internal use that we consider cool and possibly useful for other people. E.g., We built a tool that dynamically creates a testing environment using Lambda, RDS and Fargate of our backend codebase and makes it available to a Flutter UI test suite deployed in Firebase Test Lab.

We would like to release these tools/frameworks open source, but we are a bit afraid of how much time it might consume from us.

Has anyone had experience with a situation like this? If so, how did it go?

View on HN

One benefit that comes to mind is that open source tools tend to have better code quality, documentation and less technical debt - if only just because people feel embarrassed to release things that are hacked together haphazardly. This is a good thing because it makes onboarding people easier.

The biggest risk is probably a drifting focus towards improving that tool. Unless there is some overall strategy towards segmenting out pieces and moving those into OSS, finding maintainers/audience, having an actual plan around those repos... I think your intuition of avoiding it is correct.

If it's already releasable (carved out into it's own repo, parsed for any possible security breaches, independently runnable, etc.) You can just make that public with no fan fare and agree not to do anything with it for a month or two. Let your excitement die down, see if anyone notices it or cares, then evaluate at some future date what could happen with it. If you decide no, just make it private again

We open source a lot of our tools ( https://github.com/fusionauth/?q=&type=public&language=&sort... ). We welcome contributions but definitely spend some time reviewing them.

The first thing to consider is what are your goals for releasing this code? Is it to get other folks to help? To give back to communities that have helped you? To commoditize your complement? To make a name for yourself, either for sales or hiring purposes? You might say "all of these" but which one is the primary focus. That choice will drive what makes sense.

Like some of the sibling comments mention, you just need to be rigorous about how you spend time improving the tool.

It also might be worthwhile to think about the difference between pure OSS and open development. You can have one without the other. For instance, you could post your OSS tools on your org's github and explicitly disavow any support. Any PRs that come in might be merged or maybe not, but you aren't trying to build a community of contributors.

One fav quote about startups: they don't starve, they drown. Focus on swimming.

At mixpanel we open sourced a couple of libs and utils. E.g https://GitHub.com/mixpanel/fuzzbunny.

The thinking is code that isn’t core to your business, and can be useful to others can serve as goodwill. It helps attracts other engineers and nets you a nicer brand.

Think about how much brand swag Microsoft gets from vscode and Typescript.

Reply on news.ycombinator.com