Chef has shifted away from the open source community model

https://coderanger.net/chef-open-source/

by coderanger • 12 years ago

35 32 12 years ago

forsaken• 12 years ago

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.

ebiester• 12 years ago

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.

cortesoft• 12 years ago

Seriously, if you can fork it, it is open source.

vorg2• 12 years ago

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• 12 years ago

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

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

coldtea• 12 years ago

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.

vorg2• 12 years ago

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.

nemothekid2• 12 years ago

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.

dllthomas3• 12 years ago

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

nemothekid2• 12 years ago

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

schoen3• 12 years ago

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

650REDHAIR• 12 years ago

* 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

This is the boat that we're in. Our libraries, transports, and server code are open-sourced to provide more transparency and make it an easier decision to build on or migrate to us.

As much as I'd love more community involvement- we just aren't there yet and I hope that we aren't faced with similar criticism in the future.

saraid216• 12 years ago

The article says

You lost a bunch of text at this point. Seems like it might be important.

schoen3• 12 years ago

Just not indented properly. :-) The paragraph that followed that is quoted from the article.

leccine2• 12 years ago

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.

schoen3• 12 years ago

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.

JoelMcCracken• 12 years ago

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.

mullingitover• 12 years ago

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

click170• 12 years ago

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.

dllthomas3• 12 years ago

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.

chrissnell• 12 years ago

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

viraptor• 12 years ago

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 get raised and... ignored. Even if fixing it probably takes less time than commenting that it's going to triage. Sigh...

dragonwriter• 12 years ago

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

atoponce• 12 years ago

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.

michaelmike• 12 years ago

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.

vomitcuddle• 12 years ago

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

joeevans3• 12 years ago

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• 12 years ago

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.

joeevans3• 12 years ago

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.

joeevans3• 12 years ago

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.

Chef has shifted away from the open source community model

Related Stories