HashiCorp's lack of open-source engagement

What's Your Story?
1

Having encountered Vault, Consul and Terraform in my professional life, and found them useful, but not perfect, I became enthusiastic to help improve them.

However, I’ve found that it is really difficult to get PRs merged, or issues responded to. I’ve had some luck - sometimes a PR just happens to align with something a HashiCorp developer is doing, or just gets noticed by chance. But I’ve also got a lot of open PRs stuck in limbo. My open non-draft PRs on HashiCorp repositories: https://github.com/pulls?q=is%3Aopen+is%3Apr+author%3Amaxb+org%3Ahashicorp+draft%3Afalse

I get that HashiCorp has finite engineering time. But, working within that constraint, HashiCorp could do better to make community contributions less frustrating. What we need is a way to start conversations with HashiCorp, and get replies - and if responding to everyone who wants attention isn’t possible, then at least provide some feedback that some proportion of people are getting answers, HashiCorp engineering time permitting. This could be implemented by having these conversations in a section of this forum, where people could see them happening, or by allowing people to register their PR in a queue, and providing them feedback with its progress towards getting attention.

Right now, despite the code being open-source, it doesn’t feel like the community is actually empowered to contribute.

4 Likes
2

TL;DR: yes Hashicorp could treat contributors better, but the opposite is also true and it should be a two-way street.

I for one would consider a discussion around these topics as a sign of a mature and committed community. There have been several rumblings on the forum and in the wider internet regarding the ambiguity of Hashicorp’s approach in accepting open-source contributions and community participation.

One of the best things we can do as users and potential contributors, is to organise ourselves. A community needs to be owned by its members, rather than just be a place offered by a corporate entity to facilitate discussion. One could imagine that a community decision is taken that good practice would be to vote on pull requests which we support, and that that these pull requests are prioritised in terms of how many votes they have on the PR.

Sure, there will always be corporate prerogatives and commercial imperatives that will overrule the desire of the community. But I don’t think we can place all of the onus on Hashicorp the Corp to deal with the vast unstructured mass of contributions.

Perhaps Hashicorp could take the role a bit more seriously, perhaps start a matching fund for community organisers who have buy-in from their own employers to undertake these activities… We have plenty of examples to work from, I think.

I’d love to hear more voices on this topic…

3

I don’t really understand your reply … it almost doesn’t feel like you’re replying to me at all.

Fundamentally, what is needed by the community is a more consistent communication from the people actually able to review and merge PRs, i.e. HashiCorp.

I do understand that HashiCorp may need to ration the amount of such communication, as it is a draw on their engineers’ time, which is finite - in which case, expectations need to be set on when they can get around to engaging regarding a particular contribution attempt.

None of that other stuff you brought up matters, until the root problem of community PRs being left in limbo without feedback for an extended period of time, is solved.

4

Perhaps I gave the impression that I am somehow affiliated with Hashicorp – apologies, I’m just another member if the public that comes here for fun. I really do hope that someone from the company does reply and address your initial points directly!

Since you raised the topic as a matter between Hashicorp and the community, as opposed to Hashicorp and you personally, my goal was indeed not to reply, directly. I was commenting on the topic which you raised, on which I have some feelings too. Since we find ourselves in the same community, I wanted to share my point of view. My situation is very different to yours – I’ve never contributed code to any of the products – but I can still appreciate your point.

Yes, this I think we can all agree would be nice. My point though is that one cannot merely expect behaviour to emerge spontaneously. Is it possible that you’re treating the relationship between Hashicorp (via it’s product maintainers) and the wider community as merely transactional? Perhaps that’s how they want it, perhaps that’s how the majority of people want it, I have no idea. But perhaps the relationship between “us” and “them” is a two-way street.

If we want our expectations managed , then I think it’s only fair to assume that Hashicorp wants their expectations managed. For example, if they publish a roadmap for their products, they could say that they expect contributions that align with the roadmap, not that diverge from it. If there are bugs, they expect contributions that fix those bugs.

Terraform has such a guideline. Vault’s guideline explicitly says

That said, if you want to ensure that a pull request is likely to be merged, talk to us! You can find out our thoughts and ensure that your contribution won’t clash or be obviated by Vault’s normal direction. A great way to do this is via the Vault Discussion Forum.

One can clearly see that you personally are already doing this, but I wonder if it’s the case in general.

Yes perhaps you are right on this. Certainly my intention was not to diminish your point, but to enrich it with a different point of view. I’m certain that we can agree though that without input from Hashicorp’s point of view, the discussion may become sterile.

1 Like
5

So, I’m actually having the same kind of issues as described and also agree on the fact that the community should be self-sustainable but guided by the original author (hashicorp as a whole I’d say).

But, coming to think of it, I find it not that transparant how the community is made self-sustainable. In my opinion, theforeman.org does a good job at this as it seems the “community-admins” (for a lack of better word, anyone who has contributed to the community in some way and upholds the same values as the original author I’d say), these then get some extra rights in terms of reviewing/merging/consolidation/…

At least it would provide some form of ownership and perhaps incentivize some people to also try to commit some more or more qualitative time with this community? (without falling in the dark pits of nepotism ofcourse…which is probably very easy to get into) … OTOH … wouldn’t want the community to change into StackOverflow :sweat_smile: :sweat_smile:

But this is al just a opinion based on nothing but my anecdotes.

Anywho, let’s hope the guidelines are not a “do as I say” kinda deal, in which they hopefully see this thread (and perhaps there are more threads like these) that voice some very mild concerns regarding the “cost”/benefits of our commitment to this community

6

But that’s not what I was saying at all.

HashiCorp’s business model of releasing open-source software with less features, and closed-source proprietary Enterprise editions with more features, inevitably places very significant restrictions on what non-employees can be allowed to do.

I accept that.

I’m just asking and hoping that they make the process of submitting PRs or asking for a ruling on a proposed change, be one where I have clarity on when I can expect a reply.

7

Sorry, that bit was me agreeing on @brucellino1 but perhaps off topic on my end.

Just tried to think what could help in the longer run and that is IMHO transparent communication regarding the process, at least on a macro level so we know what we might expect when proposing a change.