(no title)
jackfranklyn | 18 days ago
I build accounting automation software. The defensible part isn't the code architecture - it's years of accumulated domain knowledge. How different platforms handle VAT codes differently. How the same merchant shows up as fifteen different description strings on bank statements. What a "partial invoice payment with a currency adjustment and a bank fee" actually looks like when you need to post it correctly.
Open sourcing that would hand competitors the playbook without helping end users, because end users are bookkeepers, not developers. They don't want to read source code. They want to log in and have their transactions coded.
For developer tools the logic flips entirely - your users CAN evaluate and contribute to the source, and trust matters in a way that only auditability can satisfy (as another commenter noted about credentials). But the article's framework seems to assume your end user is technical. For vertical products where the complexity is domain knowledge rather than code patterns, staying closed is usually the right call.
lelanthran|17 days ago
So much this!
Your code is literally[1] a spec for the solution to the problem your customers are paying to solve.
If you are small, you can't make it open-source.
Once you become big, then it doesn't matter if the source leaks.
If your customers need to trust you (when you're still small):
1. They are gonna require the code in escrow anyway! ... and
2. They'd be perfectly willing to sign an NDA to view the code.
Once you are big, some of the code leaks, well, you already have a beachhead of customers, you already have trust, etc.
But when you are small, your code is the step-by-step recipe for solving a problem that people are prepared to pay large amounts of money to solve. Why would you give that away?
---------------------
[1] And I do mean "literally", and not being hyperbolic.
Terr_|17 days ago
https://en.wikipedia.org/wiki/Core_competency
thisislife2|16 days ago
lovlar|18 days ago