[chef] Re: Re: Re: Re: New RFCs: local mode and multitenancy

[Daniel DeLeo < >]

On Wednesday, September 3, 2014 at 2:12 PM, Tensibai Zhaoying wrote:
> May you explain me how dealing with multiple orgs is something taking OSS 
> mono org system in-line ?
> Sounds like efforts are (logically) on the pay system with far less efforts 
> on OSS, just maintaining more or less in-line the parts of OSS used in 
> entreprise Chef.  
> Sounds like: don't expect anything stunning in OSS model. If something 
> could be of interest it will stay in pay services only.
> Already done with UI, reports, ACL... As far as it was enhanced systems I 
> was ok with it. I fear it will become more and more a cfengine model, core 
> for all, for the others enhancements don't even count on it if you can't 
> pay in dollars...
> For the last, it's open source, just rebuild what you need...
> Sorry I may be a little caricatural for chef team, but it's my feeling as a 
> chef user spending time and giving back the fixes I need to write... And 
> sounds I'll have to reinvent an existing paying wheel again and again as my 
> needs are quite the same


For various reasons, I’m going to stick to generalities, but things will be 
much clearer soon.

On the general topic, I can say this: As a business, Chef Software needs to 
give people reasons to buy our stuff, and some of that is going to be server 
features that we don’t include in the paid version. However, we have and will 
continue to design these features in such a way that interested community 
members can recreate the functionality on their own if they wish. In some 
cases, things will be open sourced once we decide there’s enough new stuff 
that we don’t need them to differentiate (like the erlang-based Chef Server).

Here’s an example of the benefit of open APIs for OSS users: the node history 
reporting feature, on the chef-client side of things, is built upon an event 
stream that anyone can create a plugin for. A community member was interested 
in integrating chef-client with the Foreman tool, and I pointed them at the 
relevant client-side reporting code and APIs. Based on that, they were able 
to integrate Chef with foreman 
(https://github.com/theforeman/chef-handler-foreman) with all the same data 
that chef-client sends to the proprietary reporting service. And I’ve further 
had no trouble recommending that users look at this as an alternative to the 
proprietary reporting service if they can’t afford that or want an open 
source solution.

I’ll finish up by saying there’s enough negative examples in the Open Source 
community of projects becoming crippled by the company that “owns” them, that 
it’s a valid concern. But I also think CHEF’s overall track record here has 
been pretty good. Also, if you feel strongly about these topics, you can join 
the developer meeting in IRC, which occurs every two weeks. The next one is 
tomorrow at 9AM Pacific time (aka America/Los Angeles).

--  
Daniel DeLeo