

Chef has shifted away from the open source community model - coderanger
https://coderanger.net/chef-open-source/

======
schoen
I think it's strange to say that a project with source code published under an
open source license isn't open source because it isn't developed in a
collaborative way with public input. We need different terminology to
distinguish these things.

There are a number of closely-held and opaque projects that practice software
development in a not-particularly-transparent way and don't solicit or welcome
input from the general public. Their output can still be open source, though!
It's just not what people have grown to expect.

Historically, a lot of the Free Software Foundation's projects were like this.
They didn't offer public access to their version control systems, the
development was primarily done by officially FSF-approved developers, and they
made (sometimes relatively infrequent) periodic official source releases with
lots of big changes. Some people called these intermittent releases "throwing
code over the transom". They didn't always specifically invite the public to
take an ongoing active role (though of course outside developers did
contribute patches).

Another interesting example is NetHack (whose official Dev Team is famously
secretive and slow to make official releases), and, until recently (except for
the licensing problems) TrueCrypt. And, so I've heard, the Android Open Source
Project.

The article says

The original idea behind “the commons” was that by everyone putting in a
little bit we could build software better and more sustainably.

I find this a little historically suspect. It depends on whose notion of the
commons and at what point in software history. Some notions of nonproprietary
software with rather long historical pedigrees include: it's culturally weird
to restrict who can use software or for what; it's too much bother to try to
restrict the use or distribution of software; end users deserve control and
freedom when they use software; making software available for unrestricted use
helps it become part of infrastructure that its developers and other people
value; getting open source software out there helps commoditize complementary
goods.

And there are some rather concrete reasons that someone would want open source
software instead of proprietary software even if it's not developed in a
collaborative way _at all_.

* Transparency about what the software does

* The ability to do audits for backdoors, bugs, and malware

* The right to fork the code if one's interests or judgments diverge sharply from the upstream developers' over the long run

* Avoiding the risk of abandonware if the upstream developer goes out of business or decides to stop developing the software

~~~
leccine
Well you can do audits for backdoors and malware without having the source
code. It is a common misconception in open source communities that you cannot
do these without the source. If you check the pro security guys, they do not
care about source code too much, it makes exploitation a bit easier but that
is it. On the top of that, having the source code does not guarantee that you
will find the security bugs either. See OpenBSD weakened crypto.

~~~
schoen
I think this is something of a continuum from actively hostile to external
audit (proprietary EULAs and legal threats; binary code obfuscation) to
actively welcoming of it (an open source project like Tor that will give
advice to researchers who are studying or reviewing it, or other projects that
try to encourage audits in other ways).

I agree that it's much more feasible to read binaries than we tend to think,
and that they're intelligible artifacts that many people do make a habit of
studying.

~~~
leccine
Yes there is a continuum and there are great Tor like projects in that sense.
Where you end up on that continuum mostly depends on the reviewing process.

------
ebiester
Chef is licensed under the Apache license. That makes it open source.

Chef, however, is not really a community project. There are many open source
projects managed like this.

I don't think this is a pedantic difference: Chef respects the four freedoms,
even if they don't incorporate these changes back to the root.

That said, I wouldn't be in a hurry to put through a pull request in most
cases myself. I wouldn't feel too invested in this tool. But it's not
proprietary.

~~~
vorg
> licensed under the Apache license. That makes it open source

> [...] not really a community project. There are many open source projects
> managed like this

Some open source projects start off as community projects but morph into
cathedralic ones, hijacked by a few to exclude the many. Even though it still
uses an open source license such as Apache, people familiar with it's formerly
more open community-oriented processes stop calling it _open source_.

~~~
nosefrog
That point of view is in conflict with the Open Source Initiative's definition
of "Open Source"[0]

[0] [http://opensource.org/osd-annotated](http://opensource.org/osd-annotated)

------
coldtea
> _Yes, in the literal sense the code is open for viewing and modification,
> but the open source ethos is more than just that. It is about communities
> building software together._

Tons of open source software is mostly controlled by one company.

If it's available by the open source rules it's good enough for me.

If there was a big enough pool of people interested in having a community
about it, they'd fork the project anyway -- as it happened with MySQL etc.

~~~
vorg
Some open source cathedrals do the opposite - they encourage outsiders to
build addons to the project, then they fork the addon and bundle it as part of
the primary software distro, leaving the outsider outside.

------
vomitcuddle
"Not Open Source" is the wrong term. It's an extreme example of a cathedral
project. See:
[http://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar](http://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar)
.

Slightly off-topic, but Android is another good example of a project where the
LICENSE is open, but the ethos behind the project are not. The source code
releases are licensed under the Apache License, but they're aimed at device
manufacturers. Not at users. Not at developers. Not at ROM makers. Google
doesn't care about your stinkin' custom ROM.

How many people outside of Google do you know who have contributed a (non-
security) patch upstream to Android? Can you clone the Android source from a
public VCS to see what is being worked on in the next, yet unannounced
release? Where was the Honeycomb source code before Ice Cream Sandwich got
released?

If someone decided to fork Android, what kind of changes could they make and
still remain compatible with apps designed for Google's version of Android?
APIs and compatibility definition documents serve as Google's insurance
against forking.

Someone ought to invent a pejorative term for this kind of projects. It may be
an open source project. But does it represent the same collaborative ethos as
the Linux Kernel, Mozilla or GNU? No.

This isn't about free software vs open source. This is about open source
serving a purely commercial interest (having the Google ecosystem on as many
third-party devices as possible) vs innovation and collaboration.

Any respectable person calling themselves a hacker would not call these "shut-
in" projects truly open.

------
mullingitover
Chef is not a true Scotsman?

Edit: drive by downvotes! Okay seriously, open source is easily defined[1].
This essay is saying ok they're open source, but they're not _TRUE_ open
source. Classic fallacy[2]. What the author really wants to say is that Chef
isn't open source _enough_ , but then it makes a much more exciting polemic to
question their identity as a group.

[1]
[https://www.google.com/search?q=define%3Aopen+source](https://www.google.com/search?q=define%3Aopen+source)
[2]
[http://en.wikipedia.org/wiki/No_true_scotsman](http://en.wikipedia.org/wiki/No_true_scotsman)

------
michaelmike
The term "Open Source (tm)" was invented to co-opt the free software
movement... so that corporations could do exactly what corporations are doing.

Your rant is 16 years late, and whatever delusions you may have of some shared
"open source model" are just that--delusions.

------
dragonwriter
The community model -- ESR's "Bazaar" \-- is made more viable by open source
licensing (it does not seem to be strictly _impossible_ with closed licensing
models, but its unlikely to be attractive to participants), but really is
conceptually a very different thing than open source. In fact, that model
evolved as a _consequence_ of open source licensing rather than being its
motivation -- the motivation was, well, the Four Freedoms, as "open source"
started as Free Software, motivated by ideology, the _pragmatic_ evolution --
and the name "open source" \-- focussed on a number of perceived benefits, of
which the community/bazaar model was clearly one but not the only one.

So, really, the reference to open source -- either the strong one in the
original article title ("Chef is not open source") or the weaker one in the
current HN title ("Chef has shifted away from the open source community
model") -- are unnecessary inflammatory and distract from the real point,
which is more like "Chef has shifted toward the 'cathedral', while Noah
prefers the 'bazaar'."

------
chrissnell
There's a good reason why you see so few institutional contributors to Chef:
Chef Inc. insists that your employer sign a Contributor Licensing Agreement
(CLA) before your PR will be merged. That's a big obstacle for many companies.
There aren't a lot of legal departments that have the bandwidth to process
these agreement forms just so that one of their employees can contribute to
some other company's code base.

Back when I worked at Rackspace, I had to jump through many, many hoops [1]
just to get my one patch [2] to knife-rackspace merged. And I had it easy:
Rackspace already had a running CLA with Opscode because Rackspace _needed_
those patches to flow. Most employers could care less.

[1] [https://github.com/opscode/knife-
rackspace/pull/42](https://github.com/opscode/knife-rackspace/pull/42)

[2] [https://github.com/opscode/knife-
rackspace/commit/d394397760...](https://github.com/opscode/knife-
rackspace/commit/d3943977600c6a31825164684df1584dfa5c2e7e)

~~~
viraptor
Yes, it's really annoying. Especially if you have things that are literally 1
character issues. The amount of bureaucracy involved is enough that I'm not
going to bother. Instead bugs like
[https://tickets.opscode.com/browse/CHEF-3755](https://tickets.opscode.com/browse/CHEF-3755)
get raised and... ignored. Even if fixing it probably takes less time than
commenting that it's going to triage. Sigh...

------
atoponce
Oh brother. Chef is Free and Open Source Software as defined by the Free
Software Foundation. It's licensed under the Apache License. It doesn't get
any more clear than that.

------
nemothekid
The same could be said of Oracle's MySQL. However since MySQL is an open
source project, you could always do what the original author did - fork it.

And since the license doesn't restrict you in any way on how you can
distribute that fork, Chef is still open source.

I think this is important distinction and the title of this article just
serves to flame the Chef development team. "Open Source", much like "Free as
in Freedom", shouldn't be thrown around because you don't like how something
is run. A lot of people spent a lot of time to create the open source movement
to allow anyone to use code they wanted too. Once you start trying to create
rules such as "Open source also means you _have_ to accept _my_ commits", you
scare people away from OSS.

~~~
dllthomas
_" And since the license doesn't restrict you in any way on how you can
distribute that fork, Chef is still open source."_

You may be aware, but a few things here make me unsure - permissively licensed
software is Open Source, but copyleft software is _also_ Open Source. (And,
for the record, permissively licensed software is _also_ Free Software).

~~~
nemothekid
You are right, what I should have said "doesn't restrict you in any way on how
you can run your fork"

~~~
dllthomas
Well, it's "you can run your fork for any purpose, modify your fork freely,
and distribute your fork and those modifications under the same license." If
you can also distribute them under a more restrictive license, the license is
permissive. If you can't, the license is copyleft.

------
joeevans
> Additionally having the code on GitHub gives a nice warm and fuzzy feeling
> that there is no vendor-lock-in, even though there is no other game in town.

What about puppet and/or ansible? Is there something chef does they don't? I
haven't been keeping up with their relative capabilities, but last I checked
they were somewhat comparable. I don't know how open source puppet and ansible
are, either.

~~~
mpdehaan2
While I disagree with the premise of the blog post above and companies should
be able to decide how to run themselves, I will say Ansible was one of the top
5 projects for most OSS contributors on GitHub last year (up there with Rails,
Angular.js, and Homebrew). We have over 775 total contributors now.

I think the greatest benefit of contributors is how to learn from them,
creating a fantastic commons of learning, and they also keep things really
well polished. Ansible was built to build this commons out, and we have some
235+ modules in core because of this now, collectively maintained.

But there are also some things that community engineering has a hard time
building, and that's ok. This model doesn't work for all things, and employing
a lot of really sharp people and giving away code is totally great too.
Distributed systems can be one of those things. Crypto can be one of those
things. These are things that don't need as large of teams as "make this
systems component work on every version of Linux/Unix/Windows/other".

I don't think there should be a sense of entitlement towards everything being
100% democratic - it's not appropriate everywhere - but when you can make it
work, it can be a good thing. In cases where the code is still open, but it's
a little harder to contribute to, it's still open and you can learn from those
sources and patch them when you need to. Editorial inputs are still important.
Having a larger vision is critically important.

When those forces and needs can be balanced, great! OSS is about itch
scratching, so sometimes if you want to build something when others have
different itches (or customers do), you do have to just go out and direct some
folks to build it. And that direction may be different than a whole armada of
people may want to go, but can still get you to very interesting destinations.

For us, I think it's about alternating between those two modes - enabling the
stream of "everything" to come in from GitHub (but filtering it, reviewing it,
and making it better), but also remembering where we might like to go, and
pointing that way, and building some of those bridges to make colonization of
new areas possible.

~~~
joeevans
Thanks... that's helpful to know where Ansible is coming from in all this. You
seem to be following the management pattern of the organizations behind the
majority of the tools and frameworks I use.

------
forsaken
Curious about the default response, which is that the company hires all of the
people that work on the project. I'd be curious to see stats of the commits of
employeers versus their time of employment. I understand that this is probably
not available to a third party, but would be interesting data.

------
click170
When did 'dysfunctional' and 'Open Source' become mutually exclusive?

Not to say that all or even most OS projects are dysfunctional, I just don't
think being OS precludes a project from also being dysfunctional.

~~~
dllthomas
This isn't even really "dysfunctional" (I mean it may be, but that's not what
the OP seems to be complaining about, per se). The complaint seems to be that
the project isn't _community driven_. The great thing about it _being_ FLOSS
is that, at any time, it could _become_ community driven if ChefInc drops the
ball (too much) and people still find value in the software.

------
joeevans
While I'm still chewing on the general premise... I have to say I really like
the way the author quantified the involvement of the various parties involved
in chef. That took some work and is useful, so I'm impressed.

------
JoelMcCracken
I would say that it is open source, but it has a problem with its community.

That said, I feel you. I think this is a common phenomenon with successful
companies that make OSS.

