Chef has shifted away from the open source community model

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

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.

>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.

"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 .

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.

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 [2] http://en.wikipedia.org/wiki/No_true_scotsman

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.

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'."

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

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

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.

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.

> 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.

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.

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.

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.

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.