Hacker News new | ask | show | jobs
by joeevans 4364 days 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.

1 comments

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.

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.