OpenBao’s development seems heavily reliant on a single person, compared to multiple frequent long-term commiters to Vault. Not sure if I’d feel comfortable switching from Vault to OpenBao!
I tried linking directly to contributors for last 12 months, but you still have to select the time range manually from the dropdown :(
GitHub's charts are inaccurate and a quick glance at the commit list would tell you that: https://github.com/openbao/openbao/commits/main/ -- you have to cross some threshhold number of commits across all time in the repository to even appear in that dashboard.
Yes, I contribute a lot, but in the last three months, we've seen substantial interest from other groups (thank you SAP, Reply, Adfinis, and G-Research OSS to name a few!) and have recently promoted a fresh group of committers.
Having worked at HashiCorp, I'm rather proud of what the community has built and proud of our ability to promote external maintainers. Open governance isn't easy for corporate contributions, but it is possible and I thank my employer for letting me try. :-)
Just look at the (narrowing) feature gap and critical improvements we've landed--transactions to name one--to see why I'm optimistic.
I realise GitHub’s graph isn’t necessarily fully representative, but one personal concern is that I don’t know yet how long-term many of these new contributors will be.
That said, I also do applaud the efforts to build a community-driven fork in a similar vein to OpenTofu (which does seem to have critical mass now), and from the sounds of what you’re saying OpenBao is heading in the right direction too.
What's annoying is the one man band projects get popular and then suddenly deciding to throw it away by archiving it on github without giving the chance of others to step in.
Definitely. It's why I've been pushing for open governance and slowly building community's trust in additional maintainers to avoid burnout and ensure continuity.
It's the safe thing to do. If you endorse a fork, and the new maintainer goes rogue, it's on you. Or, let a prevailing fork naturally emerge, and hopefully that vets them a bit in the process.
It is true that most of the commits in the last 12 months were made by cipherboy, but I can assure you that the project is not a one man show. Building a community and getting traction on a project is hard work and takes time.
The organization has been slowly building trust in more committers and maintainers and so he's had to personally review many a pull request of mine in the interim. :-D
Note to clarify: I wasn’t intending to disparage the project with my original comment! I appreciate that these things take time and a lot of hard work. Just wanted to share an observation, in the knowledge that it may not hold true indefinitely :)
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.
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 ).
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.)
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].
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. :-)
The current implementation, in the beta release, differs somewhat from upstream in how it handles entities from different levels in the namespace hierarchy.
But this is a very welcome step, and I look forward to eventually replacing Vault.
By restructuring storage--which, may, yes, lead to some operational differences--we can add per-namespace seal mechanisms in our next release (v2.4.0 -- design doc https://github.com/openbao/openbao/issues/1170), giving encryption key separation. Layer that with per-namespace storage engines (or light partitions -- separate tables) and true horizontal _write_ scalability becomes a possibility.
Yep, I have been just reading that for unrelated reasons before happening on the HN post :)
At $DAYJOB I am currently dealing with rather huge Vault Enterprise install with lots and lots of namespaces.
Honestly my biggest question is how compatible using things like kubernetes operators for Vault with OpenBao instead is - it's my main hosting platform across all projects, so very interested in integration stories there
Nice! The biggest gap with Vault Enterprise that I'm hoping we'll get to next release will be horizontal scalability of read requests.
We should be fairly compatible otherwise! Our helm chart just got a few more maintainers (I confess I lack the skills to maintain it, JanMa has been doing a great job there) though we've been relying on the pre-BUSL operator and CSI from upstream due to lack of resources.
Things like ESO and Cert-Manager should just continue to work :-)
If I wasn't virulently anti-helm I'd probably help maintain it, as it is I treat Helm as necessary evil but never write any charts ^^;
Another idea I just had yesterday, and which I've seen partially executed by others, was serverless Vault/OpenBao - the tricks I've seen used various FUSE filesystems, but I wonder if an S3-compatible backend couldn't be added one day :)
We've made an effort to keep API compatibility with Vault wherever possible, also with the new namespaces implementation. Most of the tooling which works with Vault today will also work with OpenBao
Yes, implemented from scratch by the community but (mostly--barring one reported issue) the same functionality and behavior. Not storage-level compatible, we (likely?) made different storage layout decisions that I'm rather hopeful will set us up nicely for future technical improvements above and beyond Vault Enterprise.
Horizontal scalability and disaster recovery is one of the next larger features on our mind. We won't use the architecture of Performance Secondaries, and likely will transparently upgrade (existing) Standby nodes to become read-scalable. Local storage is interesting, but brings with it additional complexity that few need. Better to use namespaces with distinct storage backends (distributing active across all nodes in a cluster) to scale writes horizontally across different namespaces before looking at horizontal scalability of a single mount (which is all that local storage gives you -- it doesn't give you write scalability across namespaces).
Also on that list is external key support, similar to managed keys from Vault Enterprise, but with different configuration semantics: https://github.com/openbao/openbao/pull/1320
We currently have no plans for implementing some of the enterprise secrets bcakends (KMIP, Transform/Tokenization, KMSE, ...) though of course would be welcoming to these as well. Sync is another area that is not in the cards for the short-term.
In terms of differentiation, we have a lot of unique RFCs in-flight that I presume are not on Vault Enterprise's immediate roadmap:
Feel free to reach out if you want to discuss more or contribute in any way -- we welcome more than just code contributions, there's many ways one can help. :-)
I tried linking directly to contributors for last 12 months, but you still have to select the time range manually from the dropdown :(
OpenBao: https://github.com/openbao/openbao/graphs/contributors?from=...
Vault: https://github.com/hashicorp/vault/graphs/contributors?from=...
https://insights.linuxfoundation.org/project/openbao-2/repos... is a more accurate view.
Yes, I contribute a lot, but in the last three months, we've seen substantial interest from other groups (thank you SAP, Reply, Adfinis, and G-Research OSS to name a few!) and have recently promoted a fresh group of committers.
Having worked at HashiCorp, I'm rather proud of what the community has built and proud of our ability to promote external maintainers. Open governance isn't easy for corporate contributions, but it is possible and I thank my employer for letting me try. :-)
Just look at the (narrowing) feature gap and critical improvements we've landed--transactions to name one--to see why I'm optimistic.
I realise GitHub’s graph isn’t necessarily fully representative, but one personal concern is that I don’t know yet how long-term many of these new contributors will be.
That said, I also do applaud the efforts to build a community-driven fork in a similar vein to OpenTofu (which does seem to have critical mass now), and from the sounds of what you’re saying OpenBao is heading in the right direction too.
You can see maintainer process here: https://github.com/openbao/openbao/blob/main/MAINTAINERS.md
And TSC processes here: https://github.com/openbao/openbao/blob/main/GOVERNANCE.md
Earlier this month, we moved from LF Edge to OpenSSF to better align with our umbrella foundation and hopefully reach more people.
Have a look at the contributions for our latest beta release and you'll see that the amount of people involved in the project is growing: https://github.com/openbao/openbao/releases/tag/v2.3.0-beta2...
The organization has been slowly building trust in more committers and maintainers and so he's had to personally review many a pull request of mine in the interim. :-D
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.)
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].
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. :-)
But this is a very welcome step, and I look forward to eventually replacing Vault.
(Entities was discussed here: https://github.com/openbao/openbao/issues/1110#issuecomment-...)
Right, check out our vision post as well: https://openbao.org/blog/vision-for-namespaces/
By restructuring storage--which, may, yes, lead to some operational differences--we can add per-namespace seal mechanisms in our next release (v2.4.0 -- design doc https://github.com/openbao/openbao/issues/1170), giving encryption key separation. Layer that with per-namespace storage engines (or light partitions -- separate tables) and true horizontal _write_ scalability becomes a possibility.
At $DAYJOB I am currently dealing with rather huge Vault Enterprise install with lots and lots of namespaces.
Honestly my biggest question is how compatible using things like kubernetes operators for Vault with OpenBao instead is - it's my main hosting platform across all projects, so very interested in integration stories there
We should be fairly compatible otherwise! Our helm chart just got a few more maintainers (I confess I lack the skills to maintain it, JanMa has been doing a great job there) though we've been relying on the pre-BUSL operator and CSI from upstream due to lack of resources.
Things like ESO and Cert-Manager should just continue to work :-)
Another idea I just had yesterday, and which I've seen partially executed by others, was serverless Vault/OpenBao - the tricks I've seen used various FUSE filesystems, but I wonder if an S3-compatible backend couldn't be added one day :)
If you use that with a PostgreSQL backend (which doesn't require raft and has faster leader changes), it might be possible.
Feel free to drop me a mail as well, email is in my profile.
btw thank you very much for your effort!!!
Horizontal scalability and disaster recovery is one of the next larger features on our mind. We won't use the architecture of Performance Secondaries, and likely will transparently upgrade (existing) Standby nodes to become read-scalable. Local storage is interesting, but brings with it additional complexity that few need. Better to use namespaces with distinct storage backends (distributing active across all nodes in a cluster) to scale writes horizontally across different namespaces before looking at horizontal scalability of a single mount (which is all that local storage gives you -- it doesn't give you write scalability across namespaces).
Also on that list is external key support, similar to managed keys from Vault Enterprise, but with different configuration semantics: https://github.com/openbao/openbao/pull/1320
We currently have no plans for implementing some of the enterprise secrets bcakends (KMIP, Transform/Tokenization, KMSE, ...) though of course would be welcoming to these as well. Sync is another area that is not in the cards for the short-term.
In terms of differentiation, we have a lot of unique RFCs in-flight that I presume are not on Vault Enterprise's immediate roadmap:
- https://github.com/openbao/openbao/pull/1365 -- starting plans for a UI rewrite and high-level feature requirements
- https://github.com/openbao/openbao/pull/1357 -- per-namespace seal mechanisms
- https://github.com/openbao/openbao/issues/769 -- Restrict LIST+SCAN (recursive) to only accessible entries
- https://github.com/openbao/openbao/pull/1304 -- static key auto-unseal, to aid chaining in trusted environments
- https://github.com/openbao/openbao/pull/1341 -- declarative one-time self-initialization to aid setup
- https://github.com/openbao/openbao/pull/1302 -- inline authentication rather than existing ahead-of-time token-based authentication
and probably more I'm missing.
Feel free to reach out if you want to discuss more or contribute in any way -- we welcome more than just code contributions, there's many ways one can help. :-)