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.
burnt-resistor 9 minutes ago [-]
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.
sevg 1 hours ago [-]
Thanks for the response and calm rebuttal :)
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.
phoronixrly 6 minutes ago [-]
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.
JanMa 1 hours ago [-]
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
sevg 1 hours ago [-]
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 :)
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.
p_l 1 hours ago [-]
From reading, it's explicit choice to add more flexibility to namespace controls.
cipherboy 1 hours ago [-]
If you have reproducers for behavioral differences, happy to take issues and PRs!
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.
p_l 14 minutes ago [-]
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
cipherboy 3 minutes ago [-]
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 :-)
JanMa 6 minutes ago [-]
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
Rendered at 09:22:28 GMT+0000 (Coordinated Universal Time) with Vercel.
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.
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
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 :-)