Hacker News new | past | comments | ask | show | jobs | submit login
No Free Features (landshark.io)
74 points by alangibson 22 days ago | hide | past | favorite | 84 comments



> So let’s get one thing straight: open source developers are not volunteering to fix your problem.

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.


Fair enough. I was trying to address people that have an expectation that the maintainers are going to do work for them. I didn't have the "wouldn't it be cool if..." requests in mind.


> I look forward to a day when asking anyone to do unpaid labor is considered unethical by our industry. That goes for feature requests on open source projects ...

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.


> 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.


I don't think this is a good analogy. We have a strong social expectation that products in stores cost money. When an artist opens a shop with many paintings, each with a price tag, everyone understands that the expected exchange is money for paintings.

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?


> On the other hand, with open source, we have a different set of social conventions

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.


> 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 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

[2] https://www.jefftk.com/bass-whistle

[3] https://www.jefftk.com/p/bucket-brigade-singing


> it is in fact an ethical problem to try to get something for nothing if you break it down

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.


I'm not really talking about the software as it exists at any given moment. The right to make a copy and use it is explicitly granted by the license. I'm focused strictly on change requests.

> 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.


> I'm not really talking about the software as it exists at any given moment. The right to make a copy and use it is explicitly granted by the license. I'm focused strictly on change requests.

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.


> it's just messy to speak in ethical absolutes about unpaid labor

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.


> I'm willing to go out on a limb and say that unpaid labor where the other side is profiting is definitely bad.

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.


A feature request is not always "for nothing" - good feature requests provides developers with useful feedback, and good ideas on how to improve the software. Depending on the motivation for developing the software in the first place, a good idea on how to improve the software could be a sufficient reward in itself. E.g. imagine somebody in academia releasing the software to increase the visibility of their research, or some other situation where getting credit is sufficient reward.


Hmm, more like walking into a public installation and asking the artist if they considered adding X, since they are mostly losing time while adding to the commons.


If go with that example if there was a direct benefit to me in the addition. Feature requests are typically made based on what the requestor needs, not what they think everyone else might need.


Yeah, emphasis on the feature requests being variable. Hopefully for the burden the more inconsiderate ones create, there is at least a commensurate level of unspoken gratitude. Thanks.


Could the solution be to create a 'feature support branch', anyone with revenues under a threshold could still maybe get free access (say 100k per year), but businesses above that would need to buy an enterprise license. Basically dual-licensing it, so you get paid, but those who are trying to build side projects/etc and may or may not ever make $$ from it, still can experiment?


I don't think it's a hard and fast rule of course, there's always context.

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.


Here's a random simple request I got on icdiff: https://github.com/jeffkaufman/icdiff/issues/136

"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.


This isn't a great example since dropping a new release is pretty trivial, but consider the counterfactual where you're having trouble paying rent and you do know that ptzz is a highly placed engineer at a Fortune 500 company.

A little compensation starts to sound like a good idea.


I have no objection to people working on open source saying that they require payment to make changes. I think anyone who gets obnoxious and entitled in response to such a request is being a jerk.

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.


> report a bug

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.


I think I still don't understand how you're thinking about it. When I report a bug or file a feature request, it seems to me that you would say I am asking the author to do some unpaid labor. That is, I am asking them to fix the bug or to add my feature. A bug report is requesting a fix to previous changes, yes, but isn't it still, in your view, a request for something in exchange for nothing? If you fix a bug for me, "you pay a hefty cost in time while my cost remains 0", no?


However, other people, including the author, stand to gain from fixing a bug in features they use.

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."


There is at least one SaaS tool for this (that takes its own cut too, of course) - the name escapes me - but rather than require that the change requestor put up the full sum, it allows multiple people to chip in ('+1 I have this problem too', but with cash) so rather than sort by #people affected as some projects do (proxied by +1s on the original post in the issue usually) they could sort by #currencyunits that the community is willing to pay, which clearly isn't necessarily the same as the issue that is annoying most people.

I think GitHub also marks that a commenter (or issue opener) is a 'Sponsor' if you use that system.


> There is at least one SaaS tool for this (that takes its own cut too, of course)

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.

https://news.ycombinator.com/item?id=23551098


Is like a service that allows the devs to basically make an offer of what they will implement it for. Bonus points if the dev can give an hour estimate so the requestor can make a case with their employee for paying up based on the good hourly rate they are getting.


+$1


100% agree. "Sorry, but I don't work for free, consider sponsoring the project" should be a perfectly legitimate reason to reject a request on an open source project.


The reason that response is so rare is that people forgot the origin of open source. Once I solve my problem, it costs me nothing to give you the solution.

If you just want me to solve your problem when I don't also have it, you need to compensate me for my time.


Respectfully, this is not the origin of open source.

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.


I always understood that as a later Richard Stallman-esque take on it.

Transparency would have just been assumed by the first people to do OSS because they'd be the ones loading the programs.


It's worth reading into the history of OSS. There was a bit of sharing going on in the early 70's, but it was all being locked down before Richard Stallman and his contemporaries created the modern OSS movement via the GNU project.

https://en.wikipedia.org/wiki/History_of_free_and_open-sourc...


The term "free software" predates "open source" by many years. Stallman started work on free software (the movement and the code) many, many years before Eric S Raymond coined the term "open source".


It's about the sharing of code, whatever label you put on it. Terminology usually lags behind practice.


The terms "free software" and "open source" were created very deliberately to express different values. The conflict between those values has been the source of a lot of contention in the past. Nowadays there's less of that, probably because as the industry grows, the proportion of developers who are old enough to remember this stuff is going down.


No, you could always share your code, "Open" source adds nothing to that.

"Free" software is about preventing technology lock-in. As in "I'll share with you but only if you agree to share with me."


I think (some)people forget that that particular piece of software saves them money and/or time and think they are entitled to it (somehow). They forget that nobody owes them anything and should be grateful for the fact it's FOSS in the first place.


Sure, but what's a reasonable price to offer? $1? $10? $100? At what point does it not make sense for the end-user to sponsor a FOSS project in order to bring it up to feature parity with a proprietary equivalent if it costs more to pay for the feature than just buying the proprietary version?

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


I don't understand this post.

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.


I think what AdmiralAsshat means is: There's a gigantic gap between typical market prices for retail computer software and the hourly wage of computer programmers

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%.


It's basically a market question. Either side should be able to make an offer and you either agree on a mutually beneficial price or not.


The right price is the developer's consultant rate * number of hours it takes.

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.


It's astounding how people are susceptible to taking things personally and generally being browbeaten. Kudos to the faker.js dev for coming to this conclusion, but it's wild to me that this wasn't their default position from day 1.


How often do the faang companies actually make change requests to these projects? My understanding, not working in the space, is that they will many times upstream improvements they develop. But I wasn't aware that they were hitting oss authors with a deluge of unpaid change requests.

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.


I'm be willing to bet that the majority of feature requests that happen come from people trying to make money at the time, either as employees or entrepreneurs. Just a guess though; is love to see hard numbers.


There are people at the large tech companies who will not only push for a project to make a change they want (including doing all the coding work) but will sometimes get into the space of bullying to try and force someone to do the change for them. I've seen this numerous times.


Would you be so kind as to point to some examples? Presumably this will be visible in a Github issue or something like that, since we're talking about OSS and presumably open issue trackers.

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.


No bullying, but Facebook wanted a change in one of my repos. The engineer said it was important for “security”, but had no motivation to contribute: https://github.com/wbond/asn1crypto/issues/59. Eventually I ended up having to do the work because other organizations didn’t like that I didn’t bundle 3MB of test fixtures with the releases on PyPi.


Sure, I'm not at all surprised that bigcos make bug reports or feature requests from time to time. This one seems like an issue that was also important to Ubuntu, so a good contribution from them? Or no? And it seems like the person was pretty polite about the request?

Admittedly they could have been more specific, but that seems like a generic newb developer issue than a FAANG-specific problem.


One thing I would note is that typically engineers from bigger companies tend to email more than leaving public issues on GitHub. Especially in the security space, lots of users tend to seem to not want a public record of their conversation.


I don’t think it is a newb question, they just wanted me to revamp how I release my project and couldn’t be bothered to contribute to the goal.


> Requesting work in an economic context without offering compensation in some form is morally indefensible.

Not even close to all open source work is in an economic context though.


_Requesting_ it is fine. _Expecting_ it is not


That's why I made it clear that I'm talking about this in an economic contest.

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.


Nearly all human activity occurs in a "economic context". Doing something outside of an economic context is like that old comedy sketch about a leaking oil tanker being towed "outside the environment". Most human interactions are at some level transactional and driven by individual incentives.

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.


I’m fully in agreement with the goal here, that for-profit companies should pay for changes they request. And some companies do pay OSS projects for support. SQLite is one high profile example (https://www.sqlite.org/consortium.html), and there are others with varying degrees of success.

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?


"there is no clear or easy path to making this goal a reality everywhere"

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!


Honestly I think many companies would be willing to pay for open source if internally engineers could say, "look, we depend on this project for our success and we have a vested interest in seeing it maintained well and getting our features/bug-fixes actioned, and it's a lot cheaper for us to spend $1k/year (or whatever) than for us to pay our own developers to work on it (and not our own features)". I think a lot of business people would respond well to that, and if enough companies do that it could drive a lot of additional innovation and development in open source.


Totally, I think you’re right, a lot of companies are open to paying for it if it’s saving money and providing value. I mean, all companies already do have a software expenditure budget for commercial software.

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?


> 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.

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.


If your software is valuable to me, and I use it without paying for it, then it is unpaid labor. It is irrelevant why you made the software, and irrelevant what the transaction cost is.

> 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?


> If an OSS project needs funding, maybe it’s best to just offer it commercially in the first place?

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.


Totally agree on the goal, it would be great if companies established slush funds for their OSS support. That said, it’s not anyone’s responsibility to provide an OSS dev with fulfilling work but themselves. If they don’t want to ask for money, chances are they won’t get any. And it’s not really relevant what money is or is not a pittance for a company, they don’t generally decide their expenditures based on having spare cash, they buy what they need and try to keep what they need to a minimum. As an engineer, if I ask for a $20K budget for OSS support, chances are I will be flatly denied. The good news is many companies already do support the OSS they depend on in multiple ways. The largest tech companies are spending a great deal more than $20k on various kinds of OSS support, FAANG companies spend millions on it.

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.


We as engineers are making choices that will certain incur maintenance costs choosing any third party solution. And the taller the dependency tree the more fragile everything becomes.

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.


I'm in the same position. We have a huge budget, but literally no way to transfer money to individuals or even aggregators like GitHub. Corporate credit card use for software is forbidden. Everythi g has to go through an 18 month purchase process.

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


Having a payment processing vendor that handles OSS projects is an interesting concept. That sounds like a large hill to climb before we can get OSS project changes funded, but regardless it seems like a viable idea. As an engineer, what would you do internally to nudge things in that direction? What would you say to your manager to plant the seed and encourage it to grow upwards?


The one thing I would never do is advocate internally for 'supporting' or 'sponsoring' OSS. Managers will just hear 'we should pay for something we already get free'.

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.


Also why it makes sense for maintainers that have the capacity to offer some token "premium support" or something along those lines. "Just give this person money because we like them" is not in the vocabulary for people approving/checking expenses, "Give this person money in exchange for a service we say we want" is totally normal. Even if the "premium" is just something relatively minor like a guaranteed response (not solution) within X working days or private submission of bug reports (and thus not having to worry about redacting logs etc posted in public).


I think recurring support contracts or subscriptions are actually very problematic in the case because the gains will naturally go the projects highest up the dependency tree because they are the most visible.

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.


Good point, hadn't thought about the trickle-down aspect.


Nitpick but important detail:

> 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...


> They say 12 units and 60 firefighters responded to the scene.

Someone is paying the wage of all these people, and it isn't Marak. The irony.


The uninformed audience is unbelivably spoiled by free software, no other professional will even talk about any domain specific problem without charging at least one hour rate. The software professionals have hopelessly low self esteem or think they're the smartest, many are ruthlessly competitive.

Applying for jobs in our industry is such a miserable experience.


What about documentation? The maintainer doesn't need to document the package in order to solve their own problem (at least, not to the same level.) Should that be chargeable too? In which case the project will likely never get off the ground, and there'll be no money coming in for other change requests either.

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.


> There are just too many grey areas to make a blanket rule.

Indeed. I'm not trying to write a law. More like correct a social norm.


If I give you a large number of scratch tickets (such that expected value is > $0), could it be considered compensation? Starting and contributing to a side project often has EROI > 0 and for many _that_ is their compensation. Now, as for Marak who is facing homelessness etc, that's just dumb (for society to treat such a beneficial member in such a manner) .


If all the dev wants is street cred, then great. I'm not telling anyone what is good for them.

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.


Yeah, hopefully thats where new engineers hoping to cut their teeth on FOSS contributions would step in and say "I want to contribute too!"

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 ...


Worth mentioning, there are quite a few people on another thread pointing out this person is not very pleasant, having done some seriously not-ok things and has an attitude that suggests these claims are disingenuous.


You should join xscode


What's Xscode's value add beyond going to the developer directly and paying them by PayPal?


Everything the developer needs. Legal framework, a trusted 3rd party (from the user side), revenue share with other contributors, ability to manage dual-licensing for repos, and much more. the thing is, xs:code also makes it easier to BUY from the developer. and that what makes it work, for both sides.





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

Search: