I don’t understand how the reasons you list are directly related to the open source principle vs just using fewer and simpler dependencies. Most of the benefits you list for a git filesystem over a proprietary database might not hold if you instead pick a postgres database, which is still open source native.
One advantage that seems more “open sourcey” is that if you’re open source native, you’re much more likely to be able to draw on an ecosystem of tools to solve your problems, than if you use proprietary dependencies. There’s more git- and postgres-compatible tools out there than there are propertaryDB-compatible tools.
I think the example is a little confusing, but I read it as “product specific” in the sense of the data that was in the already existing database was product specific, not that the database implementation was necessarily proprietary.
Eg one of the example benefits:
For example, our hypothetical package manager is less likely to have package metadata polluted with product-specific details if it is designed to operate independently of the product.
If your tool connects to a specific, internal well known db at a minimum you have to make that connection string configurable before you could open source it. You’d have to document the schema and/or have some “init the db” functionality etc.
Another way of looking at this is “How bad would it be if your repo was leaked?”, which trivially leads to “Don’t put secrets in the repo!” Most proprietary software I’ve seen does a bad job with this:
Barely obfuscated secrets.
Encrypted secrets which could trivially have been stored in the vault where the key is stored.
I don’t understand how the reasons you list are directly related to the open source principle vs just using fewer and simpler dependencies. Most of the benefits you list for a git filesystem over a proprietary database might not hold if you instead pick a postgres database, which is still open source native.
One advantage that seems more “open sourcey” is that if you’re open source native, you’re much more likely to be able to draw on an ecosystem of tools to solve your problems, than if you use proprietary dependencies. There’s more git- and postgres-compatible tools out there than there are propertaryDB-compatible tools.
I think the example is a little confusing, but I read it as “product specific” in the sense of the data that was in the already existing database was product specific, not that the database implementation was necessarily proprietary.
Eg one of the example benefits:
If your tool connects to a specific, internal well known db at a minimum you have to make that connection string configurable before you could open source it. You’d have to document the schema and/or have some “init the db” functionality etc.
Another way of looking at this is “How bad would it be if your repo was leaked?”, which trivially leads to “Don’t put secrets in the repo!” Most proprietary software I’ve seen does a bad job with this: