Hacker News new | past | comments | ask | show | jobs | submit login

Amazon can believe whatever they want, but when they say "maintainers of an open source project have a responsibility to ensure ... " - I call bullshit.

Those maintainers owe Amazon nothing. The have no responsibility to Amazon. None.

Same as they owe me nothing.

By definition (if you use any of the more-that-two-or-so-year-old definitions of "open source"), the project is defined by "remaining free and open", in that you can always use the code and license you've been using - but there's no way anybody can make it a "responsibility" of a maintainer to to anything in the future. They could die, they could get bored, they could get an all-encompassing job, they could get a family, they could get venture capital and license any future work with a non-open source license (as Redis and Elastic have done, at least in some people's view).

The "the promise the maintainer made" was "here's some code, under GPL or aGPL, or Apache Licence, or Artistic license of BSD three clause, or whatever the promise at the time was. Take it or leave it. No future responsibility assumed or enforced. They might even have a track record of releasing more stuff under the same license/promise. But they can stop or change things whenever they want.

If Amazon wants the maintainers to do anything else (including ever committing another line of code or fixing a bug), they can wait for them to do (or not) it at their discretion, or they can pay the maintainer (or someone else) to do it (and then, depending on the license, potentially be required to release that code under the same license.

Sorry for the rant, but that line caught my eye too, and I got immediately pissed off at Amazon's sense of entitlement there. No open source maintainer owes you shit. They've shared what they've shared, and you can take it or leave it, but you taking it doesn't place any obligation or responsibility on them.

(deep breath)




Maintainers are certainly free to adopt a "take it or leave it" attitude if they want.

But most maintainers (including Elastic) don't want that. They proudly declare that their developers and users are a community, and they're steering the community to produce a great and open project on an ongoing basis. The maintainers certainly have a responsibility to follow through on such promises - or at least, if Amazon is correct and they aren't following through, they have no right to complain about a hostile fork.


Promises without consideration (e.g. unpaid) aren't enforceable.

I help out by sweeping Amazon's yard everyday, for free. "Thanks!" they say, "Any time!" I reply. But years later, I decide to stop. Amazon cries out in anguish "But you have a Responsibility!", and threatens me that if I don't clean their yard... well, they'll do it themselves.

Free maintained software suits Amazon, and some organizations / foundations provide it. Seems to work as consulting services advertising (BTW which incentivizes hard-to-use software, lots of complicated features, jumbled together... ever seen a large foundation's open source project like that?)

Some businesses fund these foundations directly, but minimally, and there's a certain... reluctance. Perhaps an unmet need there...?


Amazon is welcome to fork and welcome to point out that they might be better for users than Elastic. But the issue here is that Amazon--like many others before them--are asserting a 'right' that simply does not exist.


I don't think Amazon's trying to claim that Elastic has done something legally or morally wrong. They just don't feel Elastic has lived up to their standards for community management, so they're going to take their ball and go start a new community with higher standards.


You are 100% right. I'm not Amazon's unpaid lifetime indentured slave.


> Amazon can believe whatever they want, but when they say "maintainers of an open source project have a responsibility to ensure ... " - I call bullshit.

It is true that Amazon here is just stating their own interest and are not well placed to give lessons of open source implication. Elastic has paid many developers to build open source code.

However, Shay Bannon on his side, is too much using the word "open" for a company that is not running and from my POV cannot run a real open governance. Elastic is now a listed company and was VC backed. Presenting the integration of xpack in the core repositories as an "opening" when it's a move backwards in terms of open source governance, is not fully honest.

There is a fundamental issue with Open Source and Investor backed companies. The main goal is not open governance, but the main goal is the company.

Elastic is not clear about this. Actually not being clear means there is no open governance.

Shay Bannon won't go there, because I believe as the CEO of a listed company he can't, unless it's in the interest of Elastic's investors, which means the board should decide.

Elastic does not have to have open governance and can be a great OSS contributor nevertheless. And to the opposite, it is very possible that without very healthy Elastic.co, that there would be less OSS code.

However it raises questions about the future. What will be the next step ?

What I would prefer is to have Shay Bannon be fully honest about the fact that Elastic.co needs to be healthy for the project to be healthy unless other companies are heavily investing in the community and start contributing code. And that Elastic.co being healthy means to have a mixed model. And finally I would like to hear that Elastic.co cannot promise that this won't change because Elastic.co might have to change it if the investors decide it but that as long as he is CEO he will do his best to maintain the current mixed model as long as it is financially successful.

It would be more honest that saying "doubling down on open" when you are tainting open repositories with non open source code. There was no technical reasons that the xpack repositories could not be separate.

Also, there is a way to not give an advantage to any company in an open governance way while helping companies be healthy. You can decide to have an App store in which paying features are proposed only from core contributors that contribute more than a certain level. Business could be added to the goals of the open community.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: