Great input; not flame war enticing, just facts, and I respect your 20 year head start - implicit memory is only attainable by experiencing things first hand, and I appreciate that.
Perhaps not the greatest example was provided, but the general sentiment I was aiming for was when disdain is expressed for tools without taking the time to understand what their intended (and practical) purposes are, and how they are effectively used.
When you have used a tool and understand it well, and witness another person go off on a tangent about how "Android is complete garbage, why would they ever do this this way", you naturally question that person's capability or whether they know what they are doing. In my experience, the person venting about how a tool sucks will 15-20 minutes later realize "oh. that's why.", or otherwise head off to roll their own implementation and 15 working days later realize "oh. that's why." or get into production and cause an outage from missing several edge cases.
On the macOS topic, it is odd that the root user no longer functions as one would expect in the Unix model (for example, cli tools which can no longer list OS processes, which haven't had any issues during the amount of time I've used them). It is frustrating that a wide variety of tools no longer work correctly as a result of some of these changes as well; for example, emacs can no longer navigate my filesystem. All said and done, my day to day work has been via Linux workstations for nearly all of the past 15 years, which is partly why some of those effects are more jarring than others to me.
To clarify, I'm more looking for closure, as seeing this behaviour on HN first-hand (as opposed to the N times witnessing these sorts of issues raised by someone else) has made me question the ethicality behind how HN is operated. The escalation of frustration comes in response to experiencing it first hand.
I will try to restate my points, in as neutral of manner, so they aren't misinterpreted as attacks. This is my thought process, and I'm providing it as genuine feedback.
FTP is a protocol associated with a general air of insecurity and poor practice. Most technical people would immediately say not to use it, and that there are far better solutions which aren't fundamentally insecure. Vault is not anything like that. That is a misrepresentation and additionally an attack on the usability of their competitor's product, which is unmerited.
- does not observe the best practice of having security-oriented products be open source.
It is crucial for software in this category be open source, in order to have them widely vetted, and for vulnerabilities not to be incentivized to hold onto (and sold), vs reporting to the vendor. The team have reached their decision that they will NOT open source it https://news.ycombinator.com/item?id=24720669 If I cannot build my own binaries (even if unreproduceable builds), I cannot trust the vendor. Additionally, I must trust them to operate and secure it as a public multi-user system better than one could in their own infrastructure under several layers separating it from the public. Humans are prone to mistakes, closed source software engineers make the same mistakes made in open source, only they have employees who's primary task is shipping new features-not fixing a bug which no one may see until it comes out that it's been actively exploited for years; let people improve the overall security, and encourage the only people looking for vulnerabilities to be those who would benefit from exploiting them personally, or by reselling them to the highest bidder.
- demonstrated that the are willing to say things which aren't true, or that they just didn't care to verify the details before stating them as fact.
The authors make the black/white distinction between "you use Dropbox if you aren't paranoid" and "there are self-hosted options if you care about that, but they aren't qualified because you can only use them this way", despite it not being the case. It's a spectrum, and you can achieve the same results with either offering, only with one your only choice is to trust them and that they have things so tight that several malicious employees would be subverted.
- used their employees' previous employers to legitimize their product.
As someone who may be selecting security-oriented tools for a project, and as a someone who has experienced a lot of issues specifically with their engineering/operations firsthand, Uber engineering as a point pushes me away from considering this tool. Uber has also been criticized many times for unethical actions; sure, engineers may often be simply heads-down and following a spec, but I would rather work with someone who didn't just "follow orders". As someone evaluating your offering, my specific feedback is that you will push people like myself away by leaning on that as part of your marketing/branding, particularly when it involves secret management - a topic which is highly dependent on unbreakable morals.
---
I'll stop there, but these are all legitimate concerns, which their prospective customers may consider. My contribution to the conversation is raising those concerns, rather just just discounting them and two years down the line this tool is everywhere and a real problem happens to a company or individual as a direct result of people being led to trust this tool/team.
Some people aren't going to politely state these things, most won't at all and will just pass by; I think the team should be prepared to address these sorts of concerns, for a variety of reasons, including risk assumed by their own investors. If they make a mistake, it's important that they own it, and not just brush things under the rug and ignore those concerned enough to raise such issues.
"An analogy: there are open source versions of Dropbox for users that don't trust Dropbox with their files (NextCloud, ownCloud, etc.), however this comes with the friction of having to host your own solution. We are more like Dropbox, where we want to create a solution that is incredibly easy to install, manage, and work with."
NextCloud: self-host OR pay for a managed option (this means someone runs it for you.)
ownCloud: self-host OR pay for a managed option (this means someone runs it for you.)
He compared it to Dropbox, Nextcloud, and ownCloud.
If ycombinator and their mods are more concerned with the promotion of one of their own investments, over discussion of its merits and feedback from the people who _would_ be the ones adopting and promoting it in their own companies if it indeed lived up to its own marketing, then I invite a ban for trying to keep hackernews honest and driven by community discussion, over a place for them to advertise, self promote, pat themselves on the back, and pad their wallets.
Questions for @bvallelunga, @tompic823, @rgmvisser
What is your philosophy on determining what behaviour helps to improve developers lives?
Does it involve leaving out or misrepresenting facts, pushing people away from making decisions based on pure data, or trying to blindly go full steam ahead with an idea over evaluating and responding to flaws that become known?
What do you think of a secret management tool, whose team leaks credentials in their marketing material but asks people who don't know them to trust they'll do any better once they are holding all their keys? Would you use this tool, knowing the people building it would rather hide and bury their mistakes than be transparent about them?
Should a product be enticing on its own, or should it need to name drop companies where their team may have worked in the past (which even those companies' ethics are regularly headlines)?
How did you decide this was a tool that need to be made? Were you the ones operating the existing tools at your previous companies, or did you read one page of those tools' docs and decide they were too hard?
Who should be in control of a company's secrets? The company, or a stranger who has done more to cause distrust in them than prove they can adapt to challenges and admit mistakes or poor decisions?
Going off how any comment questioning their poor behaviour is being downvoted and even intentionally hiding some comments now, this being a ycombinator alumni project, and any meaningful discussion about the project itself being shut down in preference of their own developers' posting meaningless "i luv how perfect you made it and it beats everything"... Yeah, this project has gross all over it now, and really should not be trusted for something as crucial as secret management.
You could have chosen to make a product that could stand on its own two feet.
You could have chosen to respond to criticism over your lack of marketing experience and mistaken choice to misrepresent your competition instead of, you know, compete with them.
You could have learned from this experience, instead of trying to trudge ahead.
To be brutally honest (as if not already), Doppler makes me wonder why not simply focus on building on-top of open solutions like Vault. Considering there is no on-prem version of Doppler, you could essentially run Vault behind the scenes and provide the experience you are aiming to deliver with Doppler, giving you a marketing strategy for free ("Ready to run secret management with a focus on usability; the fastest zero to production option for 'Enterprise' secret management"), that doesn't require contrasting yourself ("We ARE Vault; it's a great tool, we made it easier"), and could even value-add or contribute back upstream (vs trying to cannibalize someone who could be your peer), and even reduces your engineering effort and the need to revalidate all the security primitives (and have 3rd parties do that for you just by their using it).
Disclaimer; I have nothing to do with HashiCorp, they've just done right by me, have been great to the community, and are always improving and learning from their mistakes. A nerve is struck when marketing tells people that they are using the wrong tool (without backing that up with data), and making comparisons to a protocol which has fallen to the wayside aside from limited use cases but otherwise is predominantly insecure.
```
More importantly, just as we like to present information about Vault and its capabilities in the ways that we prefer, we felt it wasn't appropriate to describe the capabilities of other projects or products in ways other than their own terms.
```
It is a re-use/pivot of a name for a previous project from Brian that didn't take off:
```
Show HN: Doppler – Machine learning marketplace of pretrained models (producthunt.com) - 6 points by bvallelunga on Apr 25, 2018 | 1 comment
```
It's a cool name for sure, but after perusing the founder of this project's blog posts and other web activity, their highly misleading marketing ("you have three options: waste time, don't even try, or pay us!" https://doppler.com/blog/build-vs-manual-vs-buy | "we recreated what these specific competitors which are already established made; they sucked, you don't want to use them, take our word for it and pay us instead of looking for yourself!" https://news.ycombinator.com/item?id=24719722 ) I question their morals.
Substantive criticism: your marketing needs not be slinging mud, and referencing specific established players in your marketing material in order to give false credibility that you are a one-for-one replacement is a shady practice. I looked at your post solely because it contrasted itself from your competitors claiming superiority, and was disappointed by all of the above AND that the fact that it couldn't do the things it claimed to by making those contrasts.
All in all, disappointed to see a ycombinator funded project hoisted on HN with all the above going on, and one with a large number of investors behind it and no open source to back up their claims. This isn't just a community built tool to improve developers' lives, this is a marketing push by a corporation with the intent to get a burst of customers with misleading/questionable marketing.
Understood, and yes my comment was harsh, perhaps a bit much so
However `Enterprise tools like HashiCorp Vault and AWS Parameter Store felt like we were stuck using FTP instead of Dropbox!` is in itself bashing other peoples' work, and misleading prospective users.
It's not alright to mislead people, and the trends over the years of new engineers without a ton of experience looking at a battle-hardened, vetted system with their one specific use case and no understanding of the endless numbers of refinements that resulted in the predominant solution that solves more problems and edge cases than just their partially understood use case, is... why we have shit like this coming out of Apple (for example)
Despite being a millennial, I can't help but agree with this sentiment:
> When I try to list the contents of the Documents folder in Terminal, I get a permissions dialog, because Millennials are killing Unix.
Understand _why_ things are done the way they are before you write them off as inferior and re-invent the wheel, otherwise you'll simply discover all the things you didn't understand previously, and create effectively the same solution, only poorly implemented and without all the vetting and refinement that went into what was already there before you came and "did it better".
> I am not invalidating someone's right to privacy.
You are saying that not having the choice to choose what to share is acceptable though. Privacy isn't about having something to hide, it's about having the same rights you have with your day-to-day thoughts; you aren't forced to shout every single thought that pops into your mind, you are able to pick and choose what you would like to express and share. Privacy and encryption aim towards that goal.
with this setup, Vault will create a new database user based on the configuration you set (read-only for some services, for example), and will attach a time-to-live to those credentials; as long as the application is using them, it will renew the TTL. When an application is killed, or scaling happens, etc, and the application instance isn't using those specific credentials, Vault will clean up and remove the unused account cleanly
Can do all sorts of great things with this; for example TLS (ssl) certificate renewals, etc, as the certificate expiry IS the TTL; when a certificate needs to be renewed it can happen automatically and your application can receive any signal you choose (SIGHUP, for example)
Wait wait wait, and this is paid and hosted too? Bleh, nooooo thanks. I'm not sending private and secret key material to a bunch of ex-Uber employees (gross on that point alone), but nevermind to ones who looked at the existing market, didn't understand the tool-scape, and essentially decided to roll their own crypto...
I guess dynamic secrets are too "ftp" for Doppler, eh?
You lost the entire audience who have actually used Vault before when you claimed it was too complex for your team to understand.. Why would I trust a company staffed with a crew that can't even understand the tools they are trying to compete with
I think part of the reason people are chiming in on the distinction is that a controller is comparable to a mouse for a computer; a controller requires something else for any functionality, at which point you're comparing a general computing device that can do anything to a much more restricted special use device
Perhaps not the greatest example was provided, but the general sentiment I was aiming for was when disdain is expressed for tools without taking the time to understand what their intended (and practical) purposes are, and how they are effectively used.
When you have used a tool and understand it well, and witness another person go off on a tangent about how "Android is complete garbage, why would they ever do this this way", you naturally question that person's capability or whether they know what they are doing. In my experience, the person venting about how a tool sucks will 15-20 minutes later realize "oh. that's why.", or otherwise head off to roll their own implementation and 15 working days later realize "oh. that's why." or get into production and cause an outage from missing several edge cases.
On the macOS topic, it is odd that the root user no longer functions as one would expect in the Unix model (for example, cli tools which can no longer list OS processes, which haven't had any issues during the amount of time I've used them). It is frustrating that a wide variety of tools no longer work correctly as a result of some of these changes as well; for example, emacs can no longer navigate my filesystem. All said and done, my day to day work has been via Linux workstations for nearly all of the past 15 years, which is partly why some of those effects are more jarring than others to me.
Again, thanks for your input!