Open source is a gift, and the implicit social contract with gifts is that you don't give them out expecting something in return and you don't complain about them if you are on the receiving end.
If you cannot bare the GitHub issue page or pull requests, either disable them or ignore them. If you cannot bare collaboration in general, host your code as a .zip folder. If you have so much other stuff going on in your life, consider keeping the code to yourself altogether. If you feel frustrated by the fact that you could have made money from your code but didn't because you open sourced it, consider creating commercial projects.
The implicit social contract with gifts goes both ways. You got it as-is, don't expect a commercial relation.
If you run into trouble with your gift, and you need it fixed by a particular deadline, either fix it or pay someone to fix it. If you find documentation lacking, write it. If you don't like the release process, write your own. If you want support for hardware I don't have, either find someone who has it or give me the hardware.
To date, I've seen two product managers from remarkably large companies ask for status updates on a feature because they have other internal features that need it. You don't get to ask for status updates on gifts. You want something tracked on a neat timeline? Great, put it on your team's Jira and get it done.
Even if you have no intention of monitoring it, the Issues page provides a central place for the software's users to post bugs, discuss workarounds and alternatives, and coordinate forking the software if the original developer has stopped maintaining it.
If you just want a place to publish your code, you can use GitHub like any git repository, in a decentralized fashion. If you do that, you are not dependent on GitHub, it is just another clone.
But as soon as you start using the features of GitHub that are not git, you become dependent on the platform. AFAIK, you can't easily push and pull bug reports and discussions. If you want to start a community elsewhere, like a competing platform, or maybe a traditional mailing list, and there is already something happening on GitHub, you are creating a split.
You may also not trust GitHub and want to be able to leave at any time. Again, no problem with git, it is just a matter of changing your remote, but everything that is not in the git repository may be lost.
Make a private repo. Making it public, with a readme and ready to be consumed (via npm or the like) implies that you are sharing this with the public. You shouldn't prevent discussion in those cases imo especially if it doesn't require any effort from you to make and keep the issues page available
> If you have so much other stuff going on in your life, consider keeping the code to yourself altogether.
Hard disagree. If you experience no downside by publishing, publish by all means. As you've said we owe nobody support or interaction, so don't let anyone guilt you into thinking an unsupported, abandoned project is somehow worse than no project.
Or just publish the code on Github (or whatever platform you like) and then not interact with it. Whoever wants to make improvements can just fork your code, it's literally a button away.
This, GitHub is convenient to store code online publicly, so is GitLab and others.
You can just use the git repository and ignore everything else. For that, GitHub is free, and being git, you are not tied to a particular service, a "git clone" is all you need to migrate, you can even use several services at the same time, or self-host, online and offline.
I’ve started evaluating whether code I want to release even needs to be packaged. In cases where it doesn’t, I just wrote them up as blog posts for people to find. I don’t even bother with significant walkthroughs, I trust people can reason their way through it.
I used to do gists, but over time I’ve noticed those don’t get indexed nearly as well in Google & co. Plus there’s something nice about the old school blog feeling.
All this to say there’s sometimes middle grounds on how to release code that you want out there.
If your not willing to have the other person shame you for your gift then you shouldn't be giving gifts. Gifts are given because you enjoy the act of giving not how the gift is perceived by another person, if that rubs you the wrong way you shouldn't be giving, it's as simple as that.
> If your not willing to have the other person shame you for your gift then you shouldn't be giving gifts
That is antithetical to how I was raised to react to gifts; you never shame someone that gives you a gift you didn’t like unless it’s something completely egregious.
When you give a gift, you give a gift unconditionally, it is no longer a gift when there is a underlying expectation on the receiver. It is also a issue about perspective, just because you may consider something to be a "gift" it could be perceived as something else. For example, it could be considered as a form of manipulation by a third party, or a unwanted expectation to owe another person. It can be corrupting.
When you "give" open-source software, by placing it online, it's more analogous to placing a piece of furniture on your door-step with a sign that says "help yourself".
If you come along and take it, you've laid the expectation on yourself. Should you knock on my door and say, "I want this piece of furniture you're giving away, but I want you to deliver it and set it up in my home, since I have no means", I might decide to do so, but that's entirely out of the goodness of my heart, or I might tell you to fuck off, and that's entirely reasonable too.
If you decide to come along and use my open-source library (for example), you did your due-dil and set the expectation on yourself if it appears unsustainable and you decide to take it anyway.
I think if you look at my gift analogy it maps perfectly to your analogy. I wouldn't be surprised if I gifted code then someone contacted me and wanted to sue me or charge me for using it. That is the nature of a gift, you have no control over other people, if you have a problem with that don't give a gift, it's as simple as that.
> I wouldn't be surprised if I gifted code then someone contacted me and wanted to sue me or charge me for using it. That is the nature of a gift, you have no control over other people, if you have a problem with that don't give a gift, it's as simple as that
I agree with you on the relative conditions of gift-giving and receiving, to an extent, but I completely disagree, with OSS being considered gift-giving.
If I put some code online, like putting something on my doorstep, it's "without warranty", it's not a gift, it's there on the off-chance it's of use to someone; only they can make that determination, if they decide they want it, but don't have the means; can't get it home, can't maintain the code, anything they request beyond that point is "charity".
I might feel charitable and take the furniture to their home, or provide some maintenance on the code, but my act of placing it there for anybody and nobody entitles them to nothing from me, they don't like it, they don't take it.
I placed no burden on them by putting it there, and that's the difference with gift-giving and this; If I gift you a £1M house, and put the deeds in your name for you, I'm placing a burden on you, you didn't ask for that as the "giftee", I've potentially caused you harm even by "gifting" that to you, I can see you having some entitlement there.
OSS is not the same, if I post it online, you take it or leave it, if you take it, you're not entitled to my help/time/effort, it wasn't a gift, you placed the burden on yourself. If an individual wants some help, I may choose to offer it, if a company wants my help with it, I may choose to, or choose not to, I owe them nothing.
Of course much of this comes down to our own opinions on what putting our OSS code online is, if you consider yours to be a gift, that's fine, I don't (consider mine to be), we can agree to disagree.
Well, when you're explicitly bundling your own terms and conditions you're no longer gift giving you're in-fact entering into a explicit transactional exchange abet you also need to factor in copyright laws of said material. Which also depends on the Sovereign country copyright laws, and also your ability to enforce your copyright or ownership.
I agree with your proposition that it is not considered gift-giving. How-ever that also doesn't excuse the author from explicitly stating it in the terms in the code of the said works that they publish online, how-ever most common-wealth countries do have inherent
statutory copyright laws rights that protect the creator of said works.
> How-ever that also doesn't excuse the author from explicitly stating it in the terms in the code of the said works that they publish online, how-ever most common-wealth countries do have inherent statutory copyright laws rights that protect the creator of said works.
I think this certainly complicates things for a potential user, they're less likely to use it, I assume, if it's unclear what they are and aren't "allowed" to do with it. It would be nice if there could be some sort of implied "social contract" like we have in the real world, but I also understand that's more complicated with matters like IP.
Thinking about my response here, I think much of the difference with "code" vs the analogies is the IP. For some reason I'm able to chase some intellectual property rights on code that I would not with a piece of furniture I gave away on the street. What if I built that furniture with my own two hands, and could replicate it, just like I could my code?
Apologies, gone way off on a tangent there, but it's an interesting discussion.
Flaming bags of dog poo are also delivered while enjoying the act of giving. Anticipating the recipient's positive response is part what makes something a gift.
But you're right in a practical sense in that if you're not willing to take some punches for the work you did and gave away for free, you probably shouldn't do that on the internet.
> If your not willing to have the other person shame you for your gift then you shouldn't be giving gifts.
Not sure where you were raised but in the western world, shaming the gift giver is extremely rude and will definitely cost you your social reputation. The gift giver is considered to be right in being upset at being shamed
> But, like most people, I’m not persuaded by those who release something into the world for free, and basically guilt trip people for it.
Who guilt trips their users into donating to them?
> To bring food to the table; that’s all you have to do. The key mistake is to confuse the sustainability of your hobby with your own. Free labor is inhumane, yes. But in the case of open source software, it is self-inflicted.
> Do it at least to make your job easier. Let the FAANGs pretend they do it selflessly.
Do you perhaps not love writing software as much as the title suggests?
Is it inhumane for a cook to prepare a meal in his free time?
Is it inhumane for a mechanic to change a friends oil?
What's free labor about open source hobby projects?
> Who guilt trips their users into donating to them?
Many projects do [0][1][2]. This isn't even new, last time I downloaded ubuntu from canonical's website (before I used docker in anger), canonical had a "set this slider to 0 to download for free".
> The most common belief open source maintainers have is that offering something for free gives them the right to some of their users’ money.
Utter horse pucky.
If there's a common misconception around corporate open source, it's the belief that it will reduce the maintenance burden by sharing it with volunteer contributors, or (for major projects at least) that releasing open source code will lead them to be in control of a standard, rather than (if they are lucky) having influence over one.
But individual contributors have such differing motivations, I have no idea what the evidence base for that first line is.
And it continues in that vein. So much [citation needed].
What motivated that phrase is probably the plight of (non-corporate) open source maintainers who get very little money for a lot of work, while at the same time seeing billion-dollar companies that save a lot of money by using their software. The example of curl is maybe not the best: curl is a high profile tool, used literally everywhere, and at the same time (relatively) straightforward: it does one thing (with a lot of variants of course) and does it well, but it doesn't have as much of the "bit rot" maintenance burden that other projects have. So there are a lot of open source projects that are much more "thankless" than curl. Of course, no one forces the maintainers to give their work away for free, but then no one should be surprised if projects (even popular ones) are abandoned.
> [...] the plight of (non-corporate) open source maintainers who get very little money for a lot of work, while at the same time seeing billion-dollar companies that save a lot of money by using their software.
I don't dispute any of this -- it's really obviously a problem, particularly for certain "tent pole" projects where contributors have been horribly unrewarded.
I just don't think you can get from there to the first sentence of that article, because the reality of those unrewarded developers is that most will carry on until they starve rather than feel they have "the right" to money.
I'm not sure that I agree with a single line of this article. It's like the author views their entire world through a lens of financial transactions and can't understand why anyone else sees it differently.
He's doing way more than that. He's questioning the stated motivations of many OSS maintainers and pushing the line that career enhancement is the only reasonable motivation.
> We donate to charities to feel good and elevate our status. We give freebies to our prospects to put them at ease so that they reciprocate with a purchase. We apply for internships, we put together portfolios, and agree on grueling interviews to market ourselves as potential employees.
FOSS developers gift their tools, libraries, frameworks, applications, and corporations use them and then don't OSS their cloud control planes (AWS, Azure, GCP), UI frameworks (Apple), app stores (Apple, Google), etc, etc.
Some give, others take.
I guess that's how things work in gift economies in real life, too.
Glad someone mentioned the gift economy. So much discussion around FOSS reminds me of ideas from gift economy. E.g. the extent to which a culture assumes a gift is part of gift exchange, with some expectation of reciprocity. Or the concept of “giving while keeping”.
I think both ideas exist in copyleft licenses, but were lost in the more permissive MIT-style licenses. Sometimes I wonder if maintainers feel burned because they use more permissive licenses, which might be standard in their ecosystem, but unconsciously have a different gift culture.
> We Love Writing Software So Much, We're Willing to Do It for Free
The title is right. People love writing software a lot.
In my experience in this field, most don't love or even hate:
1. Fixing bugs, especially obscure ones.
2. Localizing.
3. Updating project dependencies.
4. Updating the project to follow the latest standards (security, internet, domain specific standards).
5. Doing especially the UI part, in a consistent way (consistent colors, spacing, workflows, the works).
6. Writing tests.
7. Setting up builds.
8. Setting up CI/CD pipelines.
9. Planning and roadmaps.
I'd argue that writing software is basically cheap. The expensive part is everything else, which means you're a professional software developer, so basically a "software accountant" that has to dot every i and cross every t, and it's what makes software provide real value.
I think it depends on people, there are people hate these and there are people love handling this and get paid or not get paid, it's the beauty of software imo, "cooperation", I may not be good enough to come up with big projects or architectures, but I can help out setting up tests or fix some minor bugs so the core developers can work on something more important.
"Open source as a career enhancement" is a rather depressing take.
I like computers and want to do more with them than just earn money. I want to call my silly code art. I want to have fun. I want to meet cool people.
It's challenging to balance it with basic human needs for shelter and food, sometimes. Maybe the idealist in me believes that it's possible to make art while still putting food on the table?
In my opinion the best take here. I programm because it's fun. Sometimes I want to share what I used time on, for others to appreciate. But one also need money to live.
Just the right time. I’m travelling now to go and deploy a software system I wrote for a NGO, at their place, for free. I am anonymous here so I am not bragging or such: I know many people doing the same, it’s a form of voluntary work, it benefits them, I know how to do it, and I am having fun. Everyone wins.
In my opinion open source software is usually not a ready to use product. More often is a library, a framework or a product prototype that need to be tailored, installed, configured, expanded and maintained by other developers do be useful and produce value. So I see it as just an agreement between developers to share efforts on build base software tools on which grow own private business. It we want to compare it to a traditional business is like a group of farmers that agree to share for free the best of seeds each one produce. So that everyone can grow a better harvest every year. So the business is not in the seeds and seeds producing, but in what you grow from that seeds.
> offering something for free gives them the right to some of their users’ money
This article misses the entire point of the Open Source movement. OS maintainers owe nothing to their users and expect nothing in return. It's that simple. Nobody owes you a bug fix or a new feature that you and your company desperately need. Implement it yourself, then contribute back. That's how it's supposed to work. If you need a feature but don't want to implement it yourself, you should consider compensating a maintainer for their work. A maintainer does not owe you their time and operates on their own release or feature schedule.
> guilt trip people for it
This is a cynical misrepresentation. Most open-source developers know that monetizing their projects is nearly impossible. It’s about passion, not entitlement.
> the goal is for it to be seen by others
Visibility and career advancement can be beneficial, but they are often secondary. Many maintainers continue their work long after securing jobs, driven by their commitment to their projects and communities.
Even after reading the entire article, I still don't understand what the author is trying to convey. In my personal opinion, open-source software is just like what the MIT license implies. By sharing the code I wrote, I give up all rights and also refuse to take on any obligations.
You don't give up rights. You allow others to use, modify, share (etc.) what you did according to the terms of the license. However, you could, e.g., at any time give it to someone else under a different license. Or use it yourself without care for the license terms.
I've never met any maintainer feeling entitled to their users' money, most commonly I've seen users feeling entitled to support, premium support and 247 support, and bespoke features, from open source maintainers, wtf is this guy talking about, just few weeks ago there were people from microsoft expecting priority fixes from ffmpeg for free
I think he just drank the capitalist cool-aid: everyhing is a financial transaction, nobody can ever do anything for reasons other than selfish financial interest.
I’m considering finding another line of work so that I can persue my lifelong passion around software without a bunch of godawful sociopaths turning the levers.
I imagine I’d be only middling as a car salesman, but it would hopefully be enough to hack for the joy of it again on nights and weekends.
If you cannot bare the GitHub issue page or pull requests, either disable them or ignore them. If you cannot bare collaboration in general, host your code as a .zip folder. If you have so much other stuff going on in your life, consider keeping the code to yourself altogether. If you feel frustrated by the fact that you could have made money from your code but didn't because you open sourced it, consider creating commercial projects.