So, the first reflex is to check whether this project offers free support/maintenance and development, a.k.a. free labour? It goes to show how perverted our current understanding of open source is.
So, the first reflex is to check whether this project offers free support/maintenance and development, a.k.a. free labour? It goes to show how perverted our current understanding of open source is.
If I understand your comment correctly, I think you’ve read my comment uncharitably.
I’m not making an entitled demand for free labor. I’m talking about business decisions.
My business uses many FOSS projects. We want to pick projects that are likely to be long-term solutions to reduce churn. (We also can’t pay for all of them or become committers on all of them. Equally, we don’t demand free support. This is just a risk-based decision making process.)
Couple of things to consider for your business:
1) If Vault's license format prevents managed hosted solutions, you might want to switch to OpenBao.
2) Vault has enterprise solutions you have to pay for; OpenBao is making those free.
3) In general, if you plan to pay for support, use Vault. If you don't plan to pay for support, use either of them, because they require the same amount of maintenance and have the same features. Since OpenBao is a fork, you can just review the ChangeLogs when you upgrade to see how far it has diverged from upstream. Once it's diverged more than you're comfortable with, you can just switch back to Vault [before you adopt diverged features] and it will be a very small change. You can also avoid using any OpenBao features which aren't compatible upstream.
It's worth considering that your business can lend legitimacy to OpenBao, which will increase its contributor share. You can simultaneously make a small, low-risk engineering decision, while helping grow an open source project [which helps your business].
alternatively, donate to openbao the amount you'd pay for Vault support. you'll help ensure the project doesn't fall into disrepair and get more influence over fix/feature prioritization than you could with Vault.
While I'm sure Vault contracts run more than what I'd care to know, the project is set up under the Linux Foundation and I've been told in the past that we as a project are capable of receiving direct donations.
If you're so inclined, please do!
We'd of course be appreciative of it, but that said, the OpenBao TSC had tabled conversations about just what we'd spend any funds on until after we moved into the OpenSSF... Which just concluded which means it might be time to get things moving again. But just to say, we may not immediately know what we'd spend any donations on. :-)
(Alternatively, hiring and retaining a maintainer or a firm working on it would also be good options. Part of the growth requirements of OpenSSF projects is to have more than a handful of companies on project leadership so increasing diversity is a key goal.)
It is a secrets manager; I think it's a fair question.
Very few individuals will want to run them, the reality is they're mostly for businesses to consume. Businesses need maintenance reliability and continuity plans and that's why I've been pushing on the project's governance aspects for a while.
We're not the next TikTok or JS framework so there'll be no flash point of popularity. Just have to put in the work and see where it goes. :-)
I'd argue that you're the one misunderstanding open source if you think that this is unfair. While there's a very real problem of people unfairly demanding things from open source projects, choosing not to use a project is perfectly fair. In fact, it's one of the _correct_ alternatives to unfairly demanding things from the project; just like someone making something open source has no obligation to do any work even if they're offered help or compensation for it, no one is obligated to use their work for any reason, and they're free to use whatever criteria they want to make the decision of whether to use it or not. The lack of obligation goes both ways; people can publish open source projects without owing anybody anything, but no one owes them anything for it either, and good faith technical criticism is fair game. (Bad faith technical criticism is bad of course, just like any bad faith takes in any other context ).