Hacker Timesnew | past | comments | ask | show | jobs | submit | bgoldy's commentslogin

James -

For the $$ questions I strongly advise you talk to your sales rep. We will make it simple for you and your scenario. It's great to see real world concepts and we are working to align how you work with how we price. I'm confident we can work something out - no need to try to solve it on your own.

As for the build release process, no - we are not releasing the release engineering pipeline work. But since I'm confident we can get to constructive, affordable commercial relationship with you this shouldn't matter.


Correct - Essentials is just a low cost suite of Chef products. We offer two suites,. Effortless Infrastructure, focused on core config mgmt and security/compliance use cases and Enterprise Automation Stack which includes all of that plus a wide range of app automation capabilities including dependency mgmt, lifecycle mgmt, etc.

see pricing for the suites at https://www.chef.io/pricing/


Cool! Thanks for following up.


@antoncohen - We will provide easily installable downloads for non-commercial, experimentation, and individual use which should make getting started with Chef just as easy today as it was yesterday.


What prevents companies from using those downloads for commercial use? Is it "just" a copyright violation (i.e., the same thing that prevents them from paying for one copy of Windows and running a thousand), or is there something in the code (limits on scaling, time bombs, etc.) to make them unsuitable for production use?


Historically the answer is nothing, or very little. The commercial products have a licensing mechanism that nags you, or at least it did. I don't know what their plan is on that - but I know they'll do it in public now. :)

Since everything Chef makes is used for production infrastructure, they have historically avoided doing anything that would break functionality for license compliance.


from our FAQ at http://www.chef.io/bmc-faq/

"All Chef’s software is mission critical and runs in a variety of different use cases and environments. As a result, we have not implemented hard enforcement and we don’t have any plans to change that. What we do have are commercial terms that we expect users of the software to honor. Users will have to accept the terms of the Chef End User License when they first run our software. Once the license acceptance has been acknowledged, acceptance can be automated to avoid the need for user input for further deployments. "


So you stop distributing free software/open source binaries while claiming to turn all of chef into open source? I really don't understand the motivations for that.


They aren't claiming to make it open source - they are making it open source. I explain my perspective on the motivation here: https://medium.com/@adamhjk/goodbye-open-core-good-riddance-...


Today we have two easy methods for getting Chef's bits. 1) www.chef.io/get-chef/ - which is intended for newer users where we collect contact information so we can help with customer success. 2) downloads.chef.io which provides all of our downloads, ungated, for advanced users.

hope this helps clarify.

Best, Brian Goldfarb CMO, Chef


> so we can help with customer success.

Lol. Your privacy policy says you do much more with user info than 'customer success'.


Point of view:) A "success" is a customer from which more money can be extracted;)


We have an email address on the landing page for folks like you -- cloudplatformstartups@google.com -- ping us, send us details, we'll get you over and take care of you. It's really more for recommending the intermediaries but it's a way to contact us -- so take the initiative :) The sentiment here is largely correct -- accelerators, VC's and others provide a great way to prevent fraud and other issues that programs like these deal with. We also offer $500 credit vouchers for folks who want to tinker and we are working on other ways (stay tuned) for people who want to evaluate for free to do so.

Hope this helps --

-Brian head of marketing, google cloud platform


We could get into and endless debate about SLA's, their meaning, and their value. I don't think our bar for GA and the SLA are correlated. nknighthb's interpretation is correct. The bar has to do with a wide variety of other factors including our commitment to the business, how we are focusing on customer support, view of go to market and investments there, technical aspects like performance consistency, data throughput, peering, private backbones, encryption at rest, hardware, and so many other layers. We could have just said "GA" in May at IO when we also had an SLA of 99.95% but the SLA isn't even close to enough. It's just a factor and definitely not the most important one.

Hope this helps clarify :)

-Brian


Hang on, I think I have just realised a mistake on my part.

In your quote on the site when you said "General Availabilty" you were referring to the releあse.

I mis-understood, I thought you were referring to "General Availability" as a synonym for uptime (Probably translated to "High Availability" in my head), not in the "released to General Availability" sense.

My apologies to all.


I know that's the historical wisdom but we are working very and investing heavily to make sure that isn't true in general, and specifically for Cloud Platform. We've scaled our support team dramatically to support the influx of paid support with GA and are working hand-in-hand with lots of customers everyday. It's obviously never perfect, but I can assure you it's important to us and we are doing everything we can to make the experience with support as good as we can.

-Brian


Perhaps, and I'm not trying to be facetious, a detailed blog post regarding firstly, that this (customer service) has been an issue in the past, and secondly, the measures that have been taken ("We've scaled our support team dramatically") to ameliorate the support problem.

I see Google developing a bad reputation for customer service (on HN at least. See https://hackertimes.com/item?id=6837249 for the most recent example) and some honest recognition of the problem could go a long way to restoring this.

I apologize if you aren't the correct person to direct this to; perhaps you can divert it to the correct channel.


Roger, sorry to hear this. Can you ping me at bgold at google.com so I can make sure you are getting the right help? Thanks!


The guys at Scalr were working on some benchmarking AFAIK. It's not up yet but I expect it will be soon-ish. http://blog.scalr.com/


regular maintenance helps with reliability because we do a lot of work proactively with power, hvac, switches, etc. which reduces likelihood of failure. Being able to perform maintenance in general is generally good for the stability of our system.

-Brian


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: