Overview
I've been thinking about open source in the defence tech industry. I was reading Supabase's Should I Open Source my Company?, which highlights the benefits of building an open source company like Supabase. I wanted to add some nuance which might be useful for certain companies and industries. All things being equal, I would strongly prefer working on open source or running an open source company. Unfortunately, not all things are equal. For example, in the context of Russian invasion of Ukraine, innovations in Ukraine last between 3 to 6 months and we need to constantly innovate just to keep up. l'd hate to open source key technologies and reduce that window of advantage to adversaries who invade countries.
Benefits
- Developers get to use their code even after they leave the company.
- It commoditises your complement. Some of the functionality that your competitors would have to reimplement are now commodities, where customers can more easily and cheaply get them. The value capture for a competitor to implement those features is now lower.
- Marketing to customers. If you were a consulting company and published some popular open source devtools, you'll be top of mind when the users of the devtools need extra help.
- You get to show your code to others, which helps with employment, branding, starting-a-startup and I think, developer street-cred (only between developers and only if the code is good 😂️).
- The supabase article has a lot more benefits, I'm keeping it DRY
Challenges
There are some circumstances where open source might be more difficult. Supabase avoids some challenges because:
- PaaS technology is iterative, not ground breaking: Supabase is a PaaS where there is a lot of competition and improvements are iterative. There is not much code that is "novel" (intellectual property someone wants to steal), it's an iteration on existing software. Extremely novel systems (e.g. algorithms, e.g. path planning/scheduling algorithms) are unique/novel, and open sourcing them could mean a competitor improves their efficiency. Please tell me if I am wrong here.
- open source is a marketing strategy that works when selling to developers. If Supabase was the first PaaS in the world, they'd probably get customers even if they weren't open source. Closed-source Firebase already exists, and plenty of other open source ones too. This works doubly well when developer-focused articles/memes are written about open source. Preaching to the choir.
- it operates in a meritocratic industry. Developers are knowledgeable and decide which platforms to use. Some industries are extremely sketchy, where customers have no idea which product is better. They may just choose the biggest brand name. If that brand name can tick a box (implements novel algorithm), many customers will choose that big brand name over the original creators of the tool.
- Their industry respects licensing. PaaS competitors have highly paid, respectful engineers who would not accept code theft or license violations. Other companies like Elastic, Terraform, Meta have licenses that treat large companies differently. This would likely be respected by competitors who can compete effectively, such as AWS and Azure. In defence, someone told me "don't work with X or Y (billion dollar companies in defence) because they have a bad reputation of stealing ideas from startups or acquiring them to effectively shut them down." Supabase's license is very open, so this point is more for other companies.
- the (self-)hosting and scaling aspect of Supabase is actually difficult, and can change at any time. This is not because of Supabase's "evil" intentions. Supabase does not open source everything. Even then, documentation about DevOps might be on a different system, not GitHub. I'll let the users or maintainers of Supabase add more detail here if possible (they're an incredibly honest, knowledgeable and open team)
Summary
TLDR: think about what type of industry you're in, the customers you have and how that affects theft, license violation or simply legal copying. If open source, consider broadcasting your status by writing many articles about it. Also, don't prioritise self hosting documentation, just focus on your users - that is the priority (this is not malicious, it's business). Think about the value that a competitor will get by reading or copying your code, and hide some important bits. Then you can decide which parts of your company to open source without turning your for-profit into a charity or bankruptcy.
This wasn't meant to be a dig at Supabase. I respect their product and the major bits they've open sourced. I know people who have worked there. I just want the other side of the story to be written down, from the perspective of someone who's worked in closed source, open source and then closed source again. I still try to open source certain things.
Disagree? Agree? Distasteful? Leave a comment!
Hiring fullstack engineers or web developers in Europe (and the UK)
If you're interested in modern yet pragmatic web technology (e.g. drizzle-orm, SQLite, Postgres, fullstack typescript like Hono.js, FastAPI, React, tailwind, etc) and aren't put off by closed source or defence tech, consider getting in contact with me at rust-ion-rocking at duck.com (relay email address courtesy of duckduckgo extension). Bonus points if you have open source projects. I do, like push and geojsons. We'll work on striking a balance between open and closed source whilst at work.