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

I think most people, at least certainly myself, do not disagree that open source infrastructure projects are often underappreciated and underfunded. However, there's a dramatic difference between the way that ESR's LBIP initiative frames the problem vs this article (not to single anyone out - this article expresses a commonly held belief among plenty of influential and intelligent people, and no doubt the person who wrote the article is one.)

To me, the money quote is here:

> If log4j2 is responsible for your company's success, you have a moral obligation to donate to the person who creates this library thanklessly.

I don't agree. I think that it is tragic if nobody does, but I draw the line at "moral obligation." Furthermore, the article doesn't really provide any sustainable solution, it just expresses that it's broken and says people should pay for it. Initiatives like ESR's LBIP proves that there are some attempts to get more funding in, but the problem is manyfold, and simply put: I don't think trying to create a new norm that there is a moral obligation to pay your dependencies is really a good idea, nor do I think it solves the problems that lead to this situation. I think that discovery and awareness of load-bearing dependencies is an even greater problem, and that plenty of entities that relied heavily on log4j had honestly not even realized it until now.

I'll repeat myself: It's good that log4j will now see additional attention and funding, if only temporarily, but it's still not fixing the sustainability problem if we only ever fund things when they become newsworthy snafus.




Maybe moral obligation is the wrong phrasing. But if you are major company with investors, perhaps a fiduciary responsibility to your shareholders and customers to fund the software?

The correct model likely looks something like a foundation to support core infrastructure projects in the open-source ecosystem. This foundation is then funded by companies most dependent on that infrastructure.


There is a simple solution: make companies pay for it. Don’t give your work away for $0. It isn’t rocket science.


Yeah, except by creating such an obligation, you are essentially throwing out the core concept of something being open source or free software. That's not solving the problem, that's more like giving up on it.


Not at all. I don't think you understand OSS. OSS is about Open Software. Not about free (as in $0) software. The only way to make OSS sustainable is to make companies pay for it.


With all due respect, I don’t think you do. Open source is about rights, and creating a secondary unwritten set of rules about obligations that are extralegal is just a more advanced way of circumventing them. Please read the DFSG, or OSI definition of open source, or the FSF definition of free software for what I mean. All of them are explicit that you can not discriminate on endeavor (explicitly including commercial) or the licensee. That’s not accidental.


> and creating a secondary unwritten set of rules about obligations that are extralegal is just a more advanced way of circumventing them

I am not sure I follow your argument here. Who is it that is creating a secondary unwritten set of rules?


OK. So let’s say I want to participate in open source. I release an open source project on the internet. The way I see it, here are my options:

1. I can release it freely, on a project forge like GitHub, and thus nobody has any obligation to pay for it. I can use dual licensing schemes and/or offer commercial support, or solicit donations, but by and large everyone from your average Joe to the fortune 100 are treated the same, because that’s part of the definition of open source and free software, and indeed, part of the draw.

2. I can release it at a cost, but still provide it under an open source license, but because it’s open source, someone can simply release the source code when they pay for it. In practice this actually has worked out this way; take a look at how this has been attempted with the Patron model for emulation software, for example.

3. Do #1 but ask politely (or impolitely) for big companies (how big?) to pay back when they take advantage of open source software. Create a culture wherein using open source projects implies obligations that may not be written out explicitly. This is a commonly expressed viewpoint when people talk about the problem of compensating open source maintainers, and it’s where the “extralegal” part comes in, wherein there are social expectations that contradict the license.

Selling software under a license that doesn’t allow redistribution would obviously fail almost any open source or free software definition, so I’m struggling to think of another potential interpretation here.


Great comment! My message is to the group of OSS maintainers that pick option 3 and then throws a tantrum when it doesn't work. My message is: Option 3 does not work and will never work. Accept it and pick another option.


Apparently, we’re on the same page. However, I think we can still do better than this. While some more organized projects will successfully find a model that helps them meet their goals, initiatives that try to help individuals externally could also (and obviously do) contribute to the solution.

It’s basically the same level of expectations on both sides: nobody is expected or obligated to do anything; they do so because they want to, or because they believe it is a mutually beneficial decision. It’s kind of like the comparison of engineer salary vs open source donations. Yeah, on one hand, open source donations are not likely to pay you enough to live in most cases. On the other hand, it’s money given to you under essentially no obligations. The same reason you can’t really complain much about the support you get from open source maintainers; there was never really any obligations.

But, I believe that open source has proven itself enough to have earned more donations and funding, and that there’s plenty more funding that could be making its way to open source if we could resolve issues with routing it there.


I dont disagree with you but I think that is a very old school of thoughts on OSS. And may be no longer accepted as such.

In the past ~5 years, most ( at least those who have been most vocal ) voices have suggested Open Source is not just about your source code being open / available, but it also means the community around it. And how everyone helps and contribute.

And these kind of thoughts has some sort of correlation with certain political ideology.


The problem runs deeper. To get companies to pay you, in particular enterprises, you have to participate in their high-touch/low value purchasing behavior. And that means you need large pockets which in turn means high prices. High prices means high expectations. Much of those $$$ go into marketing and sales, not product. Which is one reason most enterprise software sucks.

That's the opposite of what OSS devs want to do: solve problems and provide efficient solutions. Its also the opposite of what users of OSS want: easy to acquire solutions to their problems (nobody except purchase officers and lawyers actually want high-touch/low-value procurement. Everybody knows its a waste of time & money.)

Unfortunately most companies are not interested in buying solutions, but risk reduction (which they never actually get because all software comes with limited-to-the-max liability & warranty, just like OSS).

Therefore we have to change not the OSS model, but its reputation.

Licenses should say something like "free to use unless it generates commercial value. When it does you need to pay $ or risk your reputation". Sort of what the GPL does but without the virality.


I'm working on a solution quite similar to the one you've outlined. OpenFare implements payment plans in code. That means simple setups and programmatic management of payment obligations across software dependencies.

If you're interested, I've written a short article about it here: https://hackernoon.com/funding-the-next-million-open-source-...




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

Search: