4 ms·

Well, it's just another attempt at monetizing the product. Nowadays, companies and developers expect everything to be OSS (and I love it) yet it's incredibly ex

Well, it's just another attempt at monetizing the product. Nowadays, companies and developers expect everything to be OSS (and I love it) yet it's incredibly expensive to develop SW (and very few people do OSS just because of passion--I tried and failed miserably). Locking RBAC and TLS behind a paid subscription is a sure way to force companies with security teams to pay for it (or not to use it). This particular lesson comes relatively cheap--dropping your data is not the worst an attacker could do with it. Hopefully, more people will research what I'd call "security 101"...

pavel_lishin 6y ago
> Well, it's just another attempt at monetizing the product. Don't make excuses for their shitty business practices.
- gameswithgo 6y ago
  Don't tell people what to do.
- cookiecaper 6y ago
  The thing is that no one cares. It's a cultural issue. If Elastic makes it "harder" to get off the starting line by setting secure defaults, they'll get their lunch eaten by a fork called EasyElastic that people perceive as "easier". This probably isn't an excuse for Elastic anymore, but it's how Elastic was born ("easier than Solr!" -- they didn't invent full-text search, after all) and it's how whatever supplants Elastic will be born. Why is MySQL dominant over Postgres even though "referential integrity" didn't come to the game until v5? Why Docker over jails or OpenVZ? etc. People adopt technology because it's fashionable and it becomes fashionable in part because it's perceived as easy to use. Security and ease-of-use are not quite true opposites, but there's definitely some intrinsic tension. We have a lot of hapless practitioners in the space and the root problems here won't go away until we get some standards. Better solutions usually lose because crappy stuff focuses more effort on marketing and an "easy" onboarding process, where better stuff focuses on the operational complications of the real world.
bigiain 6y ago
> yet it's incredibly expensive to develop SW It _can_ be. At the same time some of the most used software in the world manages just fine without a company running paid subscription plans and locking free users out of critical security components. ElasticSearch/MongoDB/Redis et al are trying a new model for how to create OSS with a company behind it funding all/most of the development. That's OK, and I'm super interested to see how it works out long term. But there are many many counter examples of similar sized or way bigger software projects that never needed to do this. Pretty much everything that those three databases depend on to be used in applications is OSS that never had a "paid subscription" locking access up. How useful would any of them be without Linux, or Apache/Nginx, or Ruby/Python/PHP/Perl. My fear is that half-assed-OSS that does a _great_ job of "capturing developer mindshare" but a lousy job of securing free use of their software - is one day going to be the root cause of some _spectacularly expensive_ data breach, after which pointy haired bosses and less technical C suite suits are going to feel the full power of Oracle's golf-course-and-expensive-restaurant marketing army, and nobody in a company bigger than 10 or 12 people will ever be able to use any database with less that a half million a year license because "due diligence!" and "risk mitigation!" (and "Waygu steak with expensive whiskey" and "dirty free software hippies exposing you to data breaches!!!")

pavel_lishin 6y ago

> Well, it's just another attempt at monetizing the product. Don't make excuses for their shitty business practices.

gameswithgo 6y ago
Don't tell people what to do.
cookiecaper 6y ago
The thing is that no one cares. It's a cultural issue. If Elastic makes it "harder" to get off the starting line by setting secure defaults, they'll get their lunch eaten by a fork called EasyElastic that people perceive as "easier". This probably isn't an excuse for Elastic anymore, but it's how Elastic was born ("easier than Solr!" -- they didn't invent full-text search, after all) and it's how whatever supplants Elastic will be born. Why is MySQL dominant over Postgres even though "referential integrity" didn't come to the game until v5? Why Docker over jails or OpenVZ? etc. People adopt technology because it's fashionable and it becomes fashionable in part because it's perceived as easy to use. Security and ease-of-use are not quite true opposites, but there's definitely some intrinsic tension. We have a lot of hapless practitioners in the space and the root problems here won't go away until we get some standards. Better solutions usually lose because crappy stuff focuses more effort on marketing and an "easy" onboarding process, where better stuff focuses on the operational complications of the real world.

bigiain 6y ago

> yet it's incredibly expensive to develop SW It _can_ be. At the same time some of the most used software in the world manages just fine without a company running paid subscription plans and locking free users out of critical security components. ElasticSearch/MongoDB/Redis et al are trying a new model for how to create OSS with a company behind it funding all/most of the development. That's OK, and I'm super interested to see how it works out long term. But there are many many counter examples of similar sized or way bigger software projects that never needed to do this. Pretty much everything that those three databases depend on to be used in applications is OSS that never had a "paid subscription" locking access up. How useful would any of them be without Linux, or Apache/Nginx, or Ruby/Python/PHP/Perl. My fear is that half-assed-OSS that does a _great_ job of "capturing developer mindshare" but a lousy job of securing free use of their software - is one day going to be the root cause of some _spectacularly expensive_ data breach, after which pointy haired bosses and less technical C suite suits are going to feel the full power of Oracle's golf-course-and-expensive-restaurant marketing army, and nobody in a company bigger than 10 or 12 people will ever be able to use any database with less that a half million a year license because "due diligence!" and "risk mitigation!" (and "Waygu steak with expensive whiskey" and "dirty free software hippies exposing you to data breaches!!!")