No Free Features
landshark.io
landshark.io
That's not universally correct. As an open source (and non-open source too) developer I appreciate every idea of how to improve my app, by fixing a bug or by adding a feature (or even by rewriting my app entirely in a particular language - this is unlikely but may happen to be a good idea occasionally). Surely nobody should rely on the idea I will actually do what they want and when they want but nobody should ever hesitate to tell what they want.
While I'm sure there are some open source developers who see feature requests as a burden, lots of us just want to make useful software. If someone lets me know about a way that icdiff or anything else I maintain could be better, I'm happy to hear it.
I'm not always up for implementing changes, in which case I'll typically say whether a PR implementing the feature would be welcome, but it is extremely far from unethical to file a feature request.
I'm suggesting that it is in fact an ethical problem to try to get something for nothing if you break it down. It's no different than walking into an artists shop and asking if you can just have a painting. It doesn't make you a terrible person, but I think it's a problematic norm.
Now there's no requirement that the developer actually take the compensation (whatever it is). If you don't want it, add that to your README and never think of it again.
The problem with this statement is that the software was offered by the author as something for nothing in the first place.
The OSS authors propose that you walk into their shop and walk out with (a copy of) the painting. The problem isn’t taking the painting, it’s coming back later and asking for a change of background color or a new frame, and expecting that to also be free.
It’s important to be clear about this and not twist it into something that it is not, otherwise these ideas undermine the purposes of open source. If you frame it as purely a commercial exchange, then you lose the advantages that the open source movement brings to the table.
> The problem isn’t taking the painting, it’s coming back later and asking for a change of background color or a new frame, and expecting that to also be free.
Assuming the painting cost nothing to copy but costs alot to change, then I agree.
That's fine, it's just messy to speak in ethical absolutes about unpaid labor if it only applies to change requests and not the software itself. It's also messy to focus on the economic value of change requests and ignore the economic value of the software itself. It's messy to be perfectly comfortable with the open source license, but later expect that any communication with the author about the software should not fall under the terms of the license the author chose.
I'm wildly in favor of companies paying for their change requests, and wildly in favor of open source authors being paid for their work! I just don't quite agree with the framing of ethical absolutes you're proposing.
By and large, the majority of people using open source aren't making any change requests, and the majority of the people that do ask for changes are not demanding free work, they're reporting bugs, making suggestions, letting the authors know what would be more useful to them, but not expecting that it will happen. There is a minority of people (often newcomers) to OSS projects that expect responses and help, and they may be in the wrong, but the authors are under no obligation to attend to them, and often say so. All that said, many companies are already supporting OSS financially.
Why should we limit paying for OSS to change requests anyway? I'd love to see authors being paid for software that's used in commercial deployments. I'd love to see the authors compensated for their software's value. But we cannot ignore the fact that by choosing to release it openly, they are choosing to forego the requirement that they be paid. For some people, that's acceptable even if others ask for support.
> Assuming the painting cost nothing to copy but costs alot to change, then I agree.
Yes that is what I mean, and what you meant before that too, because that reflects the reality of open source software. This is why the art shop theft analogy wasn't great in the first place.
I'm willing to go out on a limb and say that unpaid labor where the other side is profiting is definitely bad.
> if it only applies to change requests and not the software itself.
I tried to break down why I think it is necessary to split these in the context of open source. I'll try to refine that point in the future.
> It's also messy to focus on the economic value of change requests and ignore the economic value of the software itself.
Much remains to be said about the economic value of the software itself. That's just not what I'm harping on right now.
> It's messy to be perfectly comfortable with the open source license, but later expect that any communication with the author about the software
I never said 'any.' Change requests are a very specific thing in our industry.
> should not fall under the terms of the license the author chose.
I don't get that. Why would communication with the developer fall under a software license?
Edit: I think you might mean that, because the source code was free, it's implied that the changes should be free. If so, that's exactly the norm I want to change and also why I split up the offer of source code from change requests. Getting the source code free should not imply you get changes free for reasons I laid out elsewhere in this discussion.
That is definitely not always true. And regardless, creation of the software itself is labor. It’s not a great idea to claim all unpaid labor is bad when the author explicitly chooses to forego payment for writing the software, and also turn around and say you’re only talking about a fuzzy gray line called change requests.
If profiting from someone else's labor without paying is bad, then why focus on change requests? Most companies who profit from OSS aren't asking for changes, but are making money.
> it’s implied that the changes should be free
No, I didn’t mean that the license implies changes should be free. I just mean that the license doesn’t help setup expectations, and the author is the one who both controls the license and the expectations.
The main issue here is expectations. I see and appreciate your goals here, it’s applaudable to vouch for people who should be getting paid.
What I don’t see is a clear and strong argument for why this shouldn’t be handled by market forces - why companies should pay without being asked, how much they should pay, and why devs shouldn’t simply charge for change requests and/or the software, if payment is what they seek.
On the other hand, with open source, we have a different set of social conventions. While the authors/maintainers are not obligated to handle bug reports or feature requests, we're generally happy to get good ones. They help us make our software better and more useful to more people. My projects are open source because I want them to be useful; I like making things. It's not something I do for money, and turning this into a consulting job wouldn't be fun. Other people can have different motivations, but I don't think I'm all that unusual in thinking about it this way.
I'm trying to understand how you think about this. Do you view it as ethical for someone to use open source software without payment? Isn't that also getting something for nothing? Is it ethical for someone to ask a question on one of my blog posts without offering to pay me for my answer?
Agreed. I'd like to see this particular convention change.
> Do you view it as ethical for someone to use open source software without payment?
Sure, assuming the license says it's ok. So I guess technically were talking about FOSS.
> Isn't that also getting something for nothing?
I didn't put this well before, but the problem isn't in getting something for nothing per se. The difference comes from the cost imposed on the other party involved. If I download your code, the cost we both pay rounds off to 0. But if you implement something for me, you pay a hefty cost in time while my cost remains 0. So all the value produced goes to me, and you get very close to nothing.
I see a problem with any situation where you end up worse off and I end up better off. This is the source of much open source project mortality. The core developer(s) give until they give out.
> Is it ethical for someone to ask a question on one of my blog posts without offering to pay me for my answer?
Depends. If they are profiting off of the response and all you get is the work of answering, then no. You will eventually get bitter and stop blogging unless you are some angelic person.
I think this is the core of our disagreement. If someone makes a feature request, and I think it makes the project better overall and decide to implement it, I have benefited. I wrote the software because I wanted it to be good and useful, and they have helped me make it better and more useful.
If someone asks for a feature that only would benefit them, that's different, but I'm also not likely to implement it. Similarly, if I were getting a large number of unpleasant entitled requests, I might get grumpy, but having those requests come with payments attached wouldn't help my feelings much. I do this for fun in my spare time; I don't want it to be a job.
> If they are profiting off of the response and all you get is the work of answering, then no.
I disagree there as well. I'll answer if I feel like answering, and if they ask an interesting question then I'm happy to do that. It doesn't matter to me whether or not they make a profit from my response. I have several blog posts [1][2][3] where I would love it if someone would make a successful commercial product out of, since that would let more people use the tech, and if someone was working in this direction I would be happy to answer questions.
[1] https://www.jefftk.com/p/footboard-v3
If it's one hobbyist asking another, nicely and without expecting anything, fine.
If it is an engineer asking nicely because it would help them do their work better... sorry, but that's asking one dev to improve the balance sheet of the other's employer.
That's one of the distinctions I'd make.
"ptzz: I would be nice with a new release so that options in .gitconfig works."
I have no idea who ptzz is, and it really doesn't matter to me whether they're a hobbyist playing around or at a company using icdiff for paid work. Either way, I was happy for a friendly reminder that I hadn't done a release in a while and that there were people looking forward to one.
A little compensation starts to sound like a good idea.
I have a strong objection to the suggestion that this be socially required. If people felt that it was unethical to make a feature request or report a bug without offering payment, most people would not make feature requests or file bugs, and we would all miss out.
I explicitly excluded bug reports in an earlier draft because those aren't generally considered 'changes', but rather fixes to previous changes. Looks like I should have left that in.
But of course there is blur there too; some bugs will require significant work and only benefit some small group of users. And sure you can still report those, but then you should (in my personal ideal world) not be surprised to hear "this will only matter if you're running this on enterprise scale, so wontfix unless paid to do so."
I think GitHub also marks that a commenter (or issue opener) is a 'Sponsor' if you use that system.
BountySource? Yeah their name escaped me too for a moment and when I was able to figure the name out I came across a post from a while back about them. Apparently they turned evil.
If you just want me to solve your problem when I don't also have it, you need to compensate me for my time.
The origin of open source is the ideal that "users should be able to see - and modify - the code that is running on their machines."
The "it costs me nothing" has also also proven to be false, because there's a pretty sizable overhead to open sourcing and maintaining an open source project, especially once it becomes popular. If there was no overhead, you wouldn't see articles like the "Pay Me or Fork This" post from earlier this morning.
Transparency would have just been assumed by the first people to do OSS because they'd be the ones loading the programs.
https://en.wikipedia.org/wiki/History_of_free_and_open-sourc...
"Free" software is about preventing technology lock-in. As in "I'll share with you but only if you agree to share with me."
To use a real-world example, I used to use a program called Tag&Rename for managing my mp3 metadata for years.[0] It had a method of scraping Amazon for album info, which I loved. When I switched to Linux, I switched over to EasyTag[1], which is a fine program, although I still find T&R still easier to use, and I miss the Amazon integration.
I would be willing to pay up to $30 to get Amazon scraping into EasyTag, because I believe in the long-term benefits of well-supported FOSS software. But beyond that, it's hard to justify, because I could just as easily pay $30 and run T&R under Wine/in a VM.
[0] http://www.softpointer.com/tr.htm [1] https://wiki.gnome.org/Apps/EasyTAG
It's worth $30 to you, so offer some amount above $0 and below $30. If the core developer won't do it for less than $30, find someone who will, or use a different tool, or live with the deficiency.
This is literally how all other markets work, or are supposed to work. Imagine having a completely unrelated market in which you are totally free to negotiate, and then complaining that it's too hard to settle on a price.
When you buy a $70 AAA game, you pay what, 1/100,000 of the development cost? 1/1,000,000?
So when you try to directly fund the development of almost anything, it's gonna seem real expensive, because you're paying 100% of the cost when you're used to paying 0.001%.
If you are the only person in the world that needs it, you should pay the full rate. If others have the same need, you call can share the price.
Now I know that reviewing an upstreamed change is also work. That's a big part of my job at work so I could hardly fail to recognize it. It would be completely reasonable to apply this policy even to code reviews. Of course in that event forking the project might be exactly what the companies would do, and I'm not sure if that would be a preferable outcome from the perspective of oss authors either.
FWIW I just went back and did some searching over the faker.js issues and I didn't see any requests that seemed obviously corporate. (I picked faker.js because that article seems to be the most recent inspiration for this discussion on this site.) Most of the non-feature request issues were malformed or from people who obviously don't know what they are doing, but the rest were bugs that could hit big corporate users or hobbyists alike. I didn't see any request that looked like it came from someone working at a FAANG, although I guess it might be hard to tell. The overall number of feature requests filed during the repo's history was only 15.
Admittedly they could have been more specific, but that seems like a generic newb developer issue than a FAANG-specific problem.
Not even close to all open source work is in an economic context though.
If you are making a SaaS for organizing church group outings, I wouldn't expect that 'pay for your change requests' would be a great model.
This is true even for personal side projects and charity work. In all Western societies and economies that I know of, it is both legal and acceptable to offer people compensation in exchange for them doing stuff for you, whatever that stuff is and whatever that compensation is.
I'm sure there are human societies in which this is totally untrue, but I would be surprised if the rules of those societies were applicable to open source software development outside of very specific situations.
The problem I see here is that there is no clear or easy path to making this goal a reality everywhere. What really happens most of the time is engineers at various companies are downloading and integrating open source code because it’s free to use as-is. These engineers aren’t managers and do not typically have the ability to spend company money on software without approvals from management, and while they should ask, the reality is that they don’t ask.
If I’m an engineer inside a for-profit company, with no explicit software budget, what steps should I take to prepare the company for offering bounties? Should something be happening before we download and integrate a new OSS project that sets a management/company expectation of paying for future changes, and what should that look like?
But I guess it is not simple to just put OSS projects in the same budget bucket as proprietary software. Companies have a special aversion to unexpected expenses. I’ve done business with companies that would rather pay a known monthly fee for all their licenses than only pay for the licenses that get used every month, simply because they can’t account for what it will cost in advance. Practically speaking, always paying bounties for changes would turn OSS into pure commercial software from the buyer’s point of view.
There are a ton of OSS projects that are supported by the author’s day job at a for-profit company. I guess I’m not convinced that if software is offered for free in the first place that it always makes sense to expect money to be offered without asking for it. If an OSS project needs funding, maybe it’s best to just offer it commercially in the first place?
I just don’t necessarily agree with the hyperbole that unpaid labor is “wrong”, because that undermines the initial OSS transaction. The software was offered for free-as-in-beer in the first place, and that is unpaid labor. It’s perfectly fine to request pay for changes, so isn’t that better and more straightfoward than not asking for money but complaining when none comes?
There’s quite a lot of overhead involved in running a business relative to an open source project, and this is probably not the kind of work that an open source developer would find fulfilling. Additionally, even if the developer is also able and willing to quit his job to bootstrap his business, that overhead adds to the cost of the software. On the other hand, it would be easy enough IMO to get companies to set aside $20K/year (give or take based on the size of the business) and task a few principal engineers with divvying it out among their open source projects. That would be a pittance for companies but it would be a big infusion for open source.
The terms of the economic exchange of any software is the author’s to set. It they want money for their work, in the majority of cases they will need to ask for it, it’s not going to be handed to them, especially when the software is given away for free in the first place. By giving the software away, the author is setting the terms of the economic exchange. Expecting the terms to change later without asking is just as bad as anyone expecting free support.
I think if we want to meaningfully support open source, we should figure out how to pay for the software in the first place to use it, not expect companies to throw a dollar in after the fact or only if they ask for changes. Making change requests does not align with the value of open source for most companies. The primary value is in it’s existence.
I'm explicitly not talking about the "software ... offered for free in the first place". I'm talking about changes to that software at someone else's request.
> I just don’t necessarily agree with the hyperbole that unpaid labor is “wrong”, because that undermines the initial OSS transaction.
I don't think this is true because of the genesis of the open source software itself. I created it for my needs. I would do it even if I didn't plan to give you a copy, but the transaction between us is near zero cost so I go ahead and let you use it too because I'm a cool guy.
> The software was offered for free-as-in-beer in the first place, and that is unpaid labor.
I'm making a claim that doing something to scratch your own itch doesn't qualify as 'unpaid labor' in any useful sense. It would be like saying doing a hobby is unpaid labor.
> It’s perfectly fine to request pay for changes, so isn’t that better and more straightfoward than not asking for money but complaining when none comes?
The current norm is to not request pay or to expect to pay. My argument is that norm should be inverted and maintainers should expect payment to be offered, and requestor should expect to offer to pay. If a specific dev doesn't want to be paid, then fine. It's really about the norm changing, not mandating individual behavior.
> My argument is that norm should be inverted
That norm is being set by the authors, and can be inverted by the authors, right? If devs want to be paid, they can and do ask to be paid, right?
Sonic think a prerequisite for success would be to have a single organization that does the payment processing get set up as a vendor with lord knows how many large companies. That's probably why it's never been done at any kind of scale
The best way to sell the idea is to make it transactional. 'We need feature X. It'll cost us N to pay the core devs for it, or we can do it in house for N^2.'
Then put together a spreadsheet of those examples and send them up the food chain come budget time.
However, if we payed for change requests in individual projects there would be the possibility for
1. money to trickle down from well sponsored projects to their dependencies when those higher level projects need changes
2. teams to spread money around by directly requesting changes to more obscure projects they depend on.
There is also no clear and easy universal path for proprietary software companies to be successful. Running a business is hard. I fully support efforts to make it easier to find financial success, especially with open source. Our expectations need to be reasonable, though. It seems that too many folks think that having a bunch of stars on Github should directly translate into rolling in the cash. But creating a product is only one part of building a successful business.
Again, better tools, better education, and more support are always great!
I dropped Drupal years ago because upgrading was such a nightmare. More component-ized solutions can still have the same problem.
Ultimately businesses are making the choices and tradeoffs whether they realize it right away or not. It'd be great if there were a lower friction way to consume and contribute without burying the real costs.
> The gist is that Marak, who’s on the brink of homelessness after his apartment building caught fire
It caught on fire likely because he was trying to make bombs: https://abc7ny.com/suspicious-package-queens-astoria-fire/64...
Someone is paying the wage of all these people, and it isn't Marak. The irony.
Applying for jobs in our industry is such a miserable experience.
Don't get me wrong, I agree in principle. There are just too many grey areas to make a blanket rule.
But what this is leading me to, is that if we go down this path, it just becomes another business model - where you build some things, and give them away, because you need to do so to have a product. And then charge for others. Nothing wrong with that at all, but it isn't as simple as the article makes out.
Indeed. I'm not trying to write a law. More like correct a social norm.
I'm arguing against a norm that I see as being frequently one-sided and occasionally actively destructive, and for something like the Norm of Reciprocity in this narrow case of feature requests on open source projects.
It doesnt have to be a full binary, can be a spectrum of outcomes where some people get paid for full time work, some take "experience"/"portfolio" payment and others are happy to just code ...