3 ms·
They also contributed a lot of work to the linux kernel like initial support for containers with cgroups in 2006-2007.
by rootlocus 8y ago
They also contributed a lot of work to the linux kernel like initial support for containers with cgroups in 2006-2007.
- antirez 8y agoI've a rule: don't consider "give back" to the community things that are strictly aligned to what you need. Google contributes a lot to the Linux kernel by other means as well, but the work to the containers was strategic for them. To really provide something back is to give $$$ or work to just make a project better regardless of your end goals. Otherwise it's great that you are doing it as OSS, but I would not consider it a "give back" from what you got.
- Karunamon 8y agoMeh. Doing the right thing for the wrong reason is still doing the right thing. If everyone benefits from their additions, it's immaterial to me what the intent of those additions were.
- SquareWheel 8y agoAnd even then is it "the wrong reasons"? Surely most third party contributions to the Linux core are from people that need a feature or support for a specific use case.
- pkulak 8y agoIsn't that the entire point of open source? I need a project, but it lacks the one feature I need. So I build the feature, contribute it back, and everyone wins. Is Google supposed to work on Amazon's needs and vice versa for them to be considered good patrons?
- rootlocus 8y agoDo you have examples of companies that "work to just make a project better regardless of [their] end goals"? I sincerely can't think of any and don't see a problem with it either. I skipped the part about giving $$$ because they already did that.
- antirez 8y agoYou are right downvoting me, I did not specify my reasoning. Basically contributing features you need in a very large project that you did not initiate yourself, leads to "featurism", more code to handle in the future, certain specific needs you accept mostly since they were contributed and saying no sometimes is hard. Instead work not interested to solve specific use cases tend to be consolidation work, or big general features work at least, where the goal is to fix something or do the right thing in some area, considering the whole public of such system, not your local needs. So the two approaches lead to different software philosophies and outcomes.