Chef has shifted away from the open source community model(coderanger.net)
coderanger.net
Chef has shifted away from the open source community model
https://coderanger.net/chef-open-source/
33 comments
>* 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.
>* 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.
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.
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.
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.
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.
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.
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.
Seriously, if you can fork it, it is open source.
> 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.
> [...] 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.
That point of view is in conflict with the Open Source Initiative's definition of "Open Source"[0]
[0] http://opensource.org/osd-annotated
[0] http://opensource.org/osd-annotated
>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.
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.
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.
"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.
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
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.
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'."
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...
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...
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...
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.
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.
"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).
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).
You are right, what I should have said "doesn't restrict you in any way on how you can run your fork"
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
That said, I feel you. I think this is a common phenomenon with successful companies that make OSS.
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