My boundaries as an open source developer(joeldenning.com) |
My boundaries as an open source developer(joeldenning.com) |
> In Slack or Github, it’s usually not necessary to mention me.
That's kinda how it has always worked in these forms of communication though - if I want X to see something, I mention. It's not that I personally would be keen on to be mentioned all the time, but I've been on open source project IRC for 20 years and it is like it is. People need to configure their client to not spam them, or not use [medium] if they can't do that. It's unreasonable to have the general populace have rules of whom to mention and whom not to mention. We all should be sparingly using it, it's async after all.
Here I am, many years later, still maintaining it and overally enjoying the work. I just chose to never take on any implied responsibility like described in the article. This means it's ok to ignore or close tickets, or simply not be active for some months if there was better things to do. So far the interest has kept up, and I'm improving it on our own terms.
A lot of principles are familiar here. Love to see it. Open source is no cakewalk, especially without boundaries.
Unfortunately this is common in many other parts of life as well; setting boundaries is important.
Which then leads to, those people are absolutely not going to read a blog post like this, they can't even read GIANT LETTERS IN BOLDFACE at the top of a github template telling them to please provide a test case / stack trace / etc.
After doing this for 16 years I have realized that while you need to put up guidelines, instructions for interacting, issue templates, etc., at some point you can't keep putting up signs to PLEASE DONT DO THIS - because the people for whom the ALL CAPS is intended for are the last people to read/ care about any of this, and the stern messaging otherwise brings the mood down for that vast majority of users who aren't going to be bothersome in any case.
You have to just have a pre-packaged response for the various things you get:
1. "hi" on IRC in private message from someone you don't know (obviously looking for help) - ignore. there's no response you can have for this person in this setting that will make the situation better (keep in mind, there are many forums / chats/ systems this person can use to get help, and they are well documented. these people ignored all that and are trying to go right to the main dev to get private help. they most certainly know how to find things because they found your nickname on an irc network. so this is overall a pretty rude move, but even then, some people just arent aware of what they're doing or how to act)
2. email asking for help - this is probably not too different from the "hi" in private message thing but I tend to give folks like this a short answer and point them to github discussions / irc, mentioning "there's some folks there who can help us further" (note the word "us", to soften the blow a bit). the emailers tend to be completely bewildered and generally lean heavily towards overall beginner types so I do try to gently guide them into the wider community for help.
3. recruiters - geezus, they just don't stop. I pretty much ignore them, which they have all caught onto these days so they email you over and over again...I will send back a one liner about 50% of the time after they've pinged me three times
4. weird link-sharing emails who want to put some kind of endorsement for some programming tool on my site that makes absolutely no sense to be in the context they are proposing - I usually just ignore these. Hard to tell if those are spam robots or what but they can be persistent with fairly emotionally charged "can you at least tell me what you'd be interested in?" kinds of replies...I mean these folks I'm sure are sending thousands of these emails out, are they sending out hundreds of frustrated third-requests to everyone who doesn't reply also?
I do feel for this developer since producing a JS web-development oriented library is going to generate lots more attention from a lot of users with relatively low levels of technical sophistication. I'm thankful that the Python world still attracts high quality people with reasonably good manners about things.
Having experienced the “overwhelmed with requests” thing myself, I now find myself thinking anyone who becomes demanding of open source maintainers is not seeing reality. These folks have day jobs, they don’t work for you.
If you’ve implemented my library in a mission critical part of your system, then feel free to fork & fix or pony up the dough. Otherwise you’ll get the update (if it should be updated at all) when/if I have a minute.
This might be a bit hostile but truly, c’mon people.
Usability-wise, one could lead with a terse bulleted list of "use cases" for which people should contact you, and how.
Then state you can't handle all the other usual reasons people want to interact with an open source developer, maybe giving examples. Then follow it with explanation of why.
People are not entitled for support but bringing something out as open source does come with some responsibilities. If not when others fork it the original author gets upset others stealing their project (assumption here).
No, it does not.
Open Source will eat your soul if you let it. Low effort drive by issues, questions, or comments are crushing. On my humble project, something like 40% of people who open issues completely ignore the issue template, which means every. single. conversation. begins with asking for the bare minimum of details needed to even help them. Then you've got PRs with literally zero info, which you're expected to spend time reviewing / understanding.
Some people will even violate the Github boundary and email you directly to ask why their issue isn't being responded to, or why their PR isn't getting merged, or whatever. Honestly? Fuck these people.
OP is spot on.
Abusive mindsets parse boundaries as an illness. So saying that someone "seems unwell" simply because they want reasonable boundaries is definitely telling on oneself.
So I'm curious: what in the writeup indicates a dislike of users?
Seems to me, that he wants to keep going on it, but isn't really a "people person," and wants to control his agenda.
I can respect that.
I managed an open-source project for a decade, that was designed to serve an ... interesting ... demographic.
I think many of the folks here, would have defecated masonry, if they got some of the contacts that I did.
But I'm a fairly tough old coot. I held my own. It wasn't pleasant, though, and I learned a great deal, about interacting with ... interesting ... people.
> When something feels like a demand (even a small demand such as “please respond to me” or “please review this pull request”), I often retreat. It is very common for me to take days, weeks, or even months off from open source because I get overwhelmed by the people asking me to do it. I experience a lot of initial anxiety due to the demand, followed by additional anxiety about me delaying my response.
Waking up at 4 am to reply to a poorly worded bug report with a demand you fix it immediately is exhausting and sucks your will to live
The worst was the CEO of a small competitor company repeatedly hassling me over slack DMs and in github issues threads shamelessly trying to get me to prioritize free work that he wanted for his clients. Separately, over a period of several weeks, this same person asked me a ton of support questions and then compiled my answers without edits or attribution into a "white paper" he used as a resource to get people into the marketing funnel for his consulting shop. I came to hate that guy, such an asshole, but I couldn't totally block him because his company was a member of the open source foundation governing the ecosystem of tools my project was under.
Honestly, it was hell. The most stress and irritation I've ever had in any job. When I started the job I thought it was a dream getting paid to do open source, but now I consider that an anti-goal for any future role.
This is the biggest annoyance for me. There's a very clear issue template on my repos. It provides concrete, reasonable requirements (for example, post the actual config that broke!) yet people frequently expect support without filling it out. Even worse, they will make drive-by comments/demands on random PRs instead of opening an issue.
It's kind of amazing how entitled people are.
Nowadays a non-templated bug issue is autoclosed.
Like "thank you, you've changed our live for the better" kinda stuff, and it always made the work of wading through the muck more bearable.
Of course if you make it your job, it will come with all the negatives a job can entail.
The best approach I have found is simply to add more automated gates/bots. If people have not done what the bot asks, there's no need to waste time/energy on them.
[1] https://journal.neilgaiman.com/2009/05/entitlement-issues.ht...
Being an active open source dev myself I can relate to this but at the same time I also have been on the other side of the fence when my oss projects didn't get a lot of traction and any mention from anyone, even if it was an issue, got me really excited and it also kinda validated my efforts.
It's like being a mini celebrity feeling happy when somebody asks for your first autograph but as you become more successful more people want your time and attention and then you don't want it anymore. Also unlike being a celebrity you may get some fame but rarely any fortune, so that makes it all the more easy to get annoyed when people try to eat your attention for their own benefit.
I know this isn't your main point, but afaik most low-level celebrities barely make money from it either. So it's actually even more similar than you thought.
From the outset i would say that most people releasing OSS stuff wants it to be used in production. thats until you get the hungry corps looking for free support. IMO at that stage an OSS maintainer needs to start a consulting company and funnel everything into it to avoid the burn. if this guy was making 6 figures consulting for those same companies, i think the conversation was different.
Unfortunately knowing how to write software is not always compatible with self-marketing and has a keen business acumen.
There seems to be a common misconception about open source. When I release software as open source, it does not mean I work for you for free, need to provide you with anything, even need to be nice to you. I may. Or I may not.
When I release software under an open source license, then we have a very specific deal. You are entitled to do certain things with the software, for example use it free of charge, or change it, or redistribute it, and I'm entitled to certain things in return, for example you keep attribution, you publish changes that you made under the same license, etc. Nothing more, nothing less. I could be an individual that hacked something in their free time, or I'm a multi-national mega-corp. Does not matter. It just means we have a deal.
It's nice if a community emerges, and if I feel like it, I may participate in it. And accept pull requests or help with troubleshooting or implement new features. But I don't have to and I don't have to feel any obligation whatsoever. Anybody who thinks otherwise has misunderstood the concept or is maliciously misusing it.
That's it.
This is misunderstood not just by users, but even by creators themselves. They feel pressure, they feel bad if they don't respond in time, or implement new requested features, or accept pull requests. They shouldn't. Open source just means I published it once with a very specific deal. I may continue to do so if it makes sense to me, but I can also just stop doing so. I implement features when I have a reason for it, for example I like to have them in the software so I can use them myself, or maybe because I'm a corp that sees a business need. But implementing them for free just because somebody asked for it, that's just asking for trouble. If you do that regularly, and not mostly because you think it's fun, but because you want to "support the community" or whatnot, you are taking steps towards burnout, and ultimately are not just hurting yourself but even the larger community, because you are fostering the expectation that that's what open source devs should do. No, they shouldn't. That's not what open source is about.
It's about a specific deal. Nothing more, nothing less.
I'm very happy for people who make it from doing serious open-source work. I think they deserve it. But at the same time I feel bad for those who build or maintain no less serious or popular work and yet couldn't make enough to worth even a portion of the time they'd spend.
But if people are contacting me about my project, they must be using it, right? Isn't that the point? Can't I just ignore the noise? What's the problem?
I eventually realized my motivations for developing open source software were rooted in vanity. Just making programs is something I do all the time, I find it very rewarding. But the part about open sourcing it, that was the vanity.
Before opening the project, nobody else was contributing anything to it, either. After opening it, all that changed was that my expectations for how people would react to it were not met. Expecting people to want to use my software in exactly the way I wanted was a hell of a lot of arrogance. Those people who were requesting features, they weren't "wrong", they just wanted different software. More like a service that did the things my software could enable, rather than building things with my software.
I don't write the software to get rich or escape a dead-end job. I used to have that fantasy, but nowadays life is pretty happy, and I also have realized the fantasy was always a myth, anyway. So in the end, the difference between writing software and writing open source software is nothing more than me wanting recognition for the thing I created; aka a vain search for glory.
I didn't like that view of myself, so I stopped opening my software.
Back in the days of SourceForge, open source software would be simply put for download. Anyone willing to collaborate, often times would first engage in the mailing lists or forums. That is not what GH Pull Requests do though, but quite the opposite. It builds on the idea that it is easier to discuss by showing code than by exchanging words. But that's just not how it works for anything beyond trivial/typo fixes. And that just frustrates everyone.
This is the flow I'd like to see GitHub allowing maintainers to choose, in addition to leaving today's flow as default:
- Allow maintainer to disable Pull Requests just like they can disable Issues/Discussions
- Allow maintainer to "Open Issue for Pull Requests"
This basically means that Pull Requests are on a per-issue basis, not per-repo. And only if the maintainers open said issue for accepting Pull Requests. This would push the contributors to first dialogue and discuss the enhancements/bugs before wasting any time writing code thay may never be accepted.
This flow would be much better for setting the right expectations, in my opinion.
It seems like it’s more frequent, but maybe that’s just me.
It’s great that GitHub exists and lowers the barrier for anyone to develop and share open source efforts. But you also become a slave to its various very well automated processes. As a creative altruistic agent, that can actually take a lot of the fun out of it. And make one feel trapped by the process machine.
It seems in old days, when things were less standardized, maintainers had more creative control over not only the code, but the process/community around it.
I’m not advocating for a demise of GitHub. Just kind of wondering if this is the price we pay.
The best thing a project can do to address burnout is to eliminate any sort of messaging option. Keep all discussions to the issue tracker and email.
What causes the most teeth grinding is when it is questions about their proprietary code. I don't care if their garbage never works! It's not going to help me or anyone else either way.
One should be happy for the work that people do make available for others. If you're not paying for it and it's run by people who just want to make something cool then you should be prepared to contribute if you want someone to go out of their way to help you.
You don't have to contribute financially or by writing/fixing code. If you need help with a bug, make sure you write good bug reports, and be patient.
Also, if you don't want spam, just turn off notifications for non important things and limit the communication channels to something you'll be able to control. That's the beauty of digital communication: you control exactly how and when people can get in touch with you.
If you build a product that uses open source libraries and you make money off that product, you should pay the people who created the open source libraries, even if they don't expect it or ask for it. Period. It's not a legal question, it's a basic middle-school-civics question of not being a piece of shit. If you can't afford to do that for all the open source libraries you use while still making a profit, you simply don't actually have a viable business model, much like how if you can't afford to tip your server you can't actually afford to go out to eat
As an author of open source projects with thousands of users: no. You should abide by the terms of the license, which I voluntarily chose and which does not have a secret passive-aggressive clause of "you're a piece of shit if you don't pay".
(Separately, the tipping model is awful and something we should be moving away from rather than expanding).
Well, the problem is that it's not so absolute. Publishing something normally invites feedback and it's awkward to completely ignore it. Just like it's awkward when you report a bug and get silence.
I'm not suggesting a real obligation, but there is... something? If there wasn't, then these requests would be treated like random mail to a famous person and just discarded.
- Always respond to the initial question/comment/PR. Not necessarily immediately. But it lets people know you have seen it and they are not being ignored. If they DM but you rather have them use another way of communicating, just point that out.
- Give people the benefit of the doubt. Some people just don't know how to ask a good question or how to report an issue in a constructive way, so just respond with a remark that nudges them in the right direction, possibly have some document ready describing how people should ask questions (for example, like https://stackoverflow.com/help/how-to-ask).
- Don't continue fruitless discussions. I don't repeat things I said earlier, unless there is something to clarify. If someone disagrees with me and I don't see the merit in their points, then so be it. At some point you just have to ignore messages, and don't feel bad about doing that. If someone DMs and you said to create a ticket instead, and they DM again saying things like "but it's just this small thing" or "but I just told you", I'll just ignore that, and if they really care about the issue they'll eventually figure it out.
- When it comes to low quality pull requests, tell the author how to improve them. Ideally, I should be able to merge PRs without any changes necessary on my part. This will both lower the amount of work I have to do, as well as educate the author so they will be more productive in the future.
- I try not to be too fussy about how people want to contribute. I'll just as happy to accept a patch sent via email as a PR. And sometimes it's just less work to copy&paste a DM into a ticket instead of educating the user.
I agree that this probably the ideal thing to do in the long run but, especially as a less social person, often it feels much easier to just do the minor fixes required myself. Training people to be good contributors is a good thing to do, but it is also something that can be very draining.
There seems to be a constant supply of people starting open source projects who are willing to support them, and I'm guessing that an alternative to this project will supersede it, resulting in people not bugging the author any more.
Although I respect the author's boundaries, that is sadly just part of the job of putting your work on the internet. This does not just stop at open source, if you put anything out for the world to consume, do know that this is what you're signing up for whether you like it or not. People will "find a way" to contact you and won't read your boundaries or even know about them before they do.
I keep an autoresponder in a notes file that I copy and paste regularly as it's a full time job to keep up with the requests.
Worst case scenario - people tell me my ideas are dumb and xyz does it better (I'm probably aware of xyz and found it lacking).
Best case scenario - the situation in TFA happens, where people act like I owe them something.
That's true of open source as well as proprietary development. Do you want other engineers to constantly contact you because you're "the $feature guy"? Or customers to do so?
No, you want a process and a team/community.
You may view this feature as making the product better, but it might not fit the vision of the owner/developer and to them it will only generate a maintenance burden and bloat.
[0]: https://console.substack.com/p/console-28?utm_source=url
I can imagine gaining a distaste for seeing companies benefit without being rewarded in return. With that, perhaps it’s time to seek out other maintainers? If we’re talking open source here, shouldn’t successful projects become co-owned (ie maintained) by the community?
While a single maintainer who creates a successful open sourced software certainly earns the discretion to choose to share their invention(s) or not, holding tightly onto the projects as opposed to donating them seems as unproductive as a random person demanding features.
But I am not the maintainer so I don’t mean to convey apathy, my completely naive, lizard brain would just want to troll the worst of them with “open a PR and we’ll talk”
That would create the problem, that people won't able to ask if a feature is desired by the maintainer. New contributors would spend time on a PR and then learn that the original developer considers that feature to be out of scope and therefore the development effort would be wasted.
I understand your wish for removing the issue tab. But there is a downside to it.
Occasionally happens to me. I mean, not dozens of times a week, but I've had a few weeks with more than a dozen times.
> fix bugs
"Please file an issue at http://the.issue.tracker/wherever"
> or build new features
"Please file an issue at http://the.issue.tracker/wherever"
> set up consultations
So, this one is interesting. I mean, it almost never happens to me, and certainly not w.r.t. my FOSS specifically. If I were looking for work, this would be a boon, would it not? And if I'm fully booked, then:
"I am currently not available for consultancy. You may inquire again, if relevant, in ____ months."
> or discuss business opportunities.
"I'm sorry, not interested. Good luck with your business."
Although I guess if there were dozens of these emails per week, I would create a private email box and keep the existing one only for FOSS-support-related business, attending to it every couple of weeks or so. And perhaps create an auto-reply with the above replies :-)
I found that working in the Linux distro space doesn't have this problem, especially in the pre-COVID times when there were annual in-person conferences and lots of socialising.
I spent too much time working on things for free (not just open source, but also voluntary work, and a couple of tech R&D ventures that ate my savings) and as a result I couldn't afford to attend any of the in-person conferences in far off countries, where the real action seemed to migrate to. That was a strategic error on my part!
LKML also become stressful for me after a decade of reading, just due to the energy to skim the mails each morning due to sheer volume. So I fell off, which was a shame because I had a very solid understanding of the entire kernel at one time.
Perhaps the Linux community is larger than Debian or more subject to churn as people change employers and thus change which part of Linux they work on. Or maybe as you say attending the conferences is a bit part of community feeling.
I'm surprised you read LKML, the volume is enough to put anyone off. If you are still interested in reading some of it, these days there is lore+lei to filter down the volume just to your personal interests.
If this code does not suit your needs, change it such that it does. We're all engineers/developers/coders/hackers with Top Notch Skills right?
Make a fix thats well thought out and well integrated, commit, pull request and hope the maintainer finds value in integrating your code into the next release.
Should you come across a maintainer that doesn't share your view of the issue and depending on licensing constraints simply maintain the code you were given for free on your own.
That or ... I dunno... Maybe pay someone? Venmo is a thing? Do you even Crypto bruh?
* I spent 5 years working for a company that successfully took this approach. Pre-GitHub of course.
* OP is totally on target.
Biggest benefit to me will be transparency. Everyone can see exactly where they are in my priority queue.
Huh. Could lead to some fun incentive structures. Want my attention? Then pay me. Like charge $1 per slot. So moving from 100th to 5th place would cost $95. Maybe increase the price-to-slot logarithmically.
Any way. It's nice to dream. A small inhibitor to me working on my OSS fulltime and exclusively is figuring out how to pay for food and rent and insurance while saving humanity (from itself).
> Put a big "this project is not maintained" warning on top, and nobody will bother you.
I think this is exactly the problem. The author never promises they would maintain the software, nor expect their definition of “this works” to match the users’. Why do they need to put up a sign in the first place for people to not assume? “Expecting things that were never promised” is pretty much the definition of self-entitlement. IMO this should be entirely the other way around. People should not expect anything unless the authors say they are willing to maintain.
It's a bit similar to what is the expected relationship between Alice and Bob after Alice saves Bob from drowning.
In some communities, Bob needs to be thankful for Alice for the rest of his life, with no more expectations of her.
In others, Alice is now responsible for Bob for the rest of her life.
When I encounter a new open source project it means that I can make it better by providing pull requests with new features, or fixing bugs. And then everyone benefits. If they choose to listen to me that's fine, but that's the icing on the cake, not the main course.
In my opinion, I think most of these issues outlined in the article are caused by lack of communication combined with unclear expectations, to be honest.
The only thing I ask of open-source library authors/maintainers is this: be upfront and clear about the nature of your library, and your level of commitment.
Is it just a hobby app? Totally fine, just put in bold text "this is a hobby app, not recommended for production use". That way, everyone knows what to expect, and if they do decide to use it in production, they do it at their own risk.
Do you feel that it is feature-complete? Then just say so, and indicate you will not be doing any more work on it.
Do you want to work on bugs whenever you feel like it? Nothing wrong with that, it's your work, but again, please just put it somewhere in writing so that any developer or PM who comes across your library knows exactly what to expect.
You painstakingly supported a library for years, got burned out and want to quit? At least try to pass it to another maintainer.
IMO these are just some very, very basic things that open-source authors can do that would alleviate a LOT of the friction that occurs in this space between them and those who decide to rely on their work.
Be kind, be clear, be upfront. That's it!
Seriously, this feels almost a bit like victim blaming. Why would an OSS maintainer need to write that something is a hobby project. It really doesn't matter, if as a company you want to rely on it, pay for it. Why should your expectations change because of what the maintainer says?
That itself is part of the problem.
I do also appreciate all the great FOSS ecosystems that I'm using. Who knows where we would be without them.
But open source software is not about some kind, selfless altruist who hacks away for free for the benefit of others. It's about publishing the source code with some attached rights and obligations for programs or libraries that have been developed to scratch an itch. Be it personal need, personal interest, learning opportunity or straight up business necessity. You publish to get a community involved to make your software better, be it through bug reports, recommendations for improvement, pull requests, etc. That ultimately benefits the author, and that's the whole point.
It's a misconception that open source software is (or should be) developed for the greater good, to be kind to one another. And by keeping to thank "kind hard working individuals" (which they often times are!), one perpetuates this misconception. It's great if kindness is a component in all of this. But it's not the central point and should not be expected to be. That's what causes threads like this one in the first place, where somebody has to complain about being exploited or getting annoyed with peoples expectations, or their own expectations with themselves, and then others opining about that.
> You painstakingly supported a library for years, got burned out and want to quit? At least try to pass it to another maintainer.
Are you serious? Above you just said that you have immense respect for open source authors. And now you say that somebody can't take it anymore and is burned out and THEN you STILL expect them to put MORE work in, despite being burned out, to pass things on? The source code is available, the license is clear, if there is anybody else who wants to maintain, they can just go and to it. Why do you keep demanding anything from the already-burned-out author that you respect immensely? Honestly, I find that deeply disrespectful.
I 1000% agree that open source contributors and maintainers don’t owe anyone anything, but if people still demand things, I’d recommend putting disclaimers like you’re recommending front and center, if at the very least so that maintainers can respond to the pushy people with a link to it.
The clear statement on this is in the license of the project. You need to read the license, which grants you certain rights to the software to see what you're being granted and what you're not getting.
In nearly every license, very specifically says that it's not supported and you're entirely on your own if you decide to use it.
If you need a higher level of assurance, you need to pay for support. Either from the author(s) if they are interested, or from third party companies who provide support for that library, if any exist.
NPM had some thoughts about providing package.json metadata in order for the customers to know the author intentions but I am not sure what happened to it.
I remember reading about it in this article: https://www.theregister.com/2020/10/28/nodejs_15_michael_daw...
> The [module] maintainers are struggling," he said. "They may have written a module, it was a hobby they did on a weekend, now they've got 20,000,000 downloads and the people who are using it > have expectations which are more than what > is appropriate for something that they're getting for free. We've worked on something that we call package support which is adding extra metadata to > the package JSON, which allows the maintainer to provide information about their intention in terms of support. So what kind of support is there? Is it best effort? Is there no support at all? Is there > a company? Is it part of a foundation?
- Michael Dawson
This is the default position for most open source licences, hobby projects or not.
I agree it is useful for hobby projects to be labelled as such, however.
SPONSORING OPEN SOURCE DEVELOPERS Rich Hickey - December 15, 2020 https://cognitect.com/blog/2020/12/15/sponsoring-open-source...
HN Thread here: https://news.ycombinator.com/item?id=25436335
Nonetheless, there are dozens of effectively abandonware ROS projects out there attached to my name— drivers for some sensor I shipped years ago and haven't touched since, interface libraries that aren't really relevant but don't have a clear alternative, stuff that was never out of the prototype phase and doesn't have anywhere close to the level of test coverage that would let me just merge much less release changes without extensive manual running of it.
I suppose I should go in and just mark them all as archived so that well-meaning people don't file issues (and even PRs) that will never be addressed or perhaps even acknowledged. And in some cases I've just granted PR authors write access and been like "there it's yours now." But none of these end states feel quite right; in all cases I end up feeling guilty and unsatisfied with how it turns out.
What feels wrong with this? Personally I'd much rather hand a project over to someone else than leave it completely archived.
I'm a full-time maintainer that has luckily made it work. Donations don't work. Carving out business specific features and paywalling has worked for me.
But it's not a tenable solution for most projects. I've been thinking about how people in your position can basically "cash out". It is sitting dormant, PR authors are too intimidated by maintenance to take the lead. Maybe some sort of robotics vertical-focussed Private Equity type organization could buy out your project (where you get paid to essentially transfer the repo to their GH org, they would then take up maintenance and monetisation)? Would you accept a deal from them? How much would you ask for one of your popular repos?
https://github.com/benbjohnson/litestream#contribution-polic...
- developer finds a cool project - developer consumes the cool project - developer finds opportunity for bug fix or enhancement - developer forks and starts working on the enhancements - developer spends hours/days writing code - developer submits a PR - developer gets a notification (upon filling the PR, or after, from a bot) - developer is now extremely frustrated - developer complains - maintainers and the developer start debating - the Pull Request storm goes viral - developer threatens to stop using cool project - maintainers handle the situation poorly (they are coders, not Public Relations people) - the community makes things worse
And so on...
I suspect that making someone go through the signup dance stopped a LOT of the worst level of morons.
Is there a code hosting service that allows public viewing but still forces people to sign up for an account before being able to do actions?
Very insightful, but is it in fact a slightly different emotion to that?
In the Mythical Man Month, Fred Brooks says:
> Why is programming fun? What delights may its practitioner expect as his reward? First [..]
> Second is the pleasure of making things that are useful to other people. Deep within, we want others to use our work and to find it helpful. In this respect the programming system is not essentially different from the child’s first clay pencil holder “for Daddy’s office.”
I don't know if this is quite vanity. That sounds a bit too negative. Is this the kind of complex emotion that Germans would have a word for but not English?
Also, Germans don't have words for things. They just remove all the whitespace from their sentences and then run around, "look at this neues word Ich hab!" :D
I'd say the need for validation describes that closely enough.
Bingo. The hard-earned wisdom of this insight right here almost completely explains all the internal issues the OP was feeling when he wrote his rather over-the-top post.
Yeah, it sucks to realize that your just as human as the next guy and that your motives aren't always as pure as you wish they were, but there is nothing at all wrong with being proud and wanting to be noticed for abilities.
Figuring out what path works for you AFTER realizing your motives aren't pure is how one solves the open-source user issue.
My point was that my reaction to things like feature requests I didn't want to build was a signal that I wasn't interested in building just a user base for the project. If what I were interested in were building a project that people wanted to use, could sell to them, etc., then I would discard my notions about what I wanted to build and I'd build what people wanted. That was the epiphany I had. I realized I had been lying to myself about my motivations. I realized that my actions proved I didn't really care about getting people to just use the software.
Because I was so annoyed by the lack of contribution, despite the obvious signals that people were using the software, I (eventually) realized that my true goal was for people to interact with my code, not my program. There's a difference there. Any feature in a program can be implemented in any number of ways. But there's necessarily only one way that it's implemented in my program. Thus to be more focused on contributions than usage implies that I care more about how people see my implementation of the features than the features themselves.
I didn't start these projects thinking, "let me make a thing that will prove my prowess as a developer". I made the things to scratch some personal itch. The software on its own fulfills that particular need.
The act of open sourcing it was a different thing entirely. It's not trivial to open source a project; there's a lot of work in trying to prepare it for use by other people. Why go through all of that? What need did I expect opening the code to fulfill for me? Opening code doesn't attract users. So few users care if a project is open or not that they can safely be ignored as a rounding error. So why focus time on opening the code, verus any other action I could take with my time?
Thus the realization that I had been deluding myself.
> Back in the days of SourceForge...
Strongly agree. The github PR is a somewhat toxic misfeature. The last thing I want in my open source projects is some rando sending some huge diff that does who knows what. Now I'm supposed to read and understand this code and figure out all the unintended side effects? And even if the code is ok it's probably missing test coverage, doc updates, etc. So filling the gaps would generate more work for me.
However, I do like and accept tiny PRs that fix very targeted things.
I wish I could put a size limit on PR diffs in github. Something like if the PR changes more than 10 lines of code, block it. File a ticket instead of discuss the proposal, don't blast me with code I don't have time to read.
- Owners are of no obligation to approve, close, merge, or interact with a PR in any way. If you don’t want to merge a PR, just don’t.
- you can include a readme which can include whatever discouragement you want.
- if you have a CONTRIBUTORS.md file, GitHub will show that to first time contributors when they submit a PR.
- I’m sure you could trivially have a GitHub action that will auto close all PRs as soon as they’re submitted.
There is a lot of performative abuse on github, where someone opens an ill-tempered or outright misleading issue, and hurls insults and then takes to twitter or reddit to try to get people to pile on, or they complain that their wall of invective was just summarily closed. And when you do ban people on github it has all kinds of weird side effects like blocking them from commenting on other project's issues where you're active.
In general, GH makes it really hard to ghost people. There have always been people who through personality or situation were unable to participate productively. Under older models of communication it was easy to simply ignore these unproductive actions without initiating any visible response that would trigger retaliation or fixation.
I see a lot of people on this thread of calling for modifications to githubs systems. I really don't see them doing that.
maybe I misunderstand GitHub but as much as I like, enjoy and benefit from GitHub I just think their mission is to cater to the long tail as much as possible. and well maybe somewhat controversial I don't actually think their main play is enabling seamless collaboration I think that's just sort of a necessity for what they're really trying to do. I'm not sure what they're really trying to do but one can imagine there must be some sort of profitable businesses where you have all the world's developers on your system.
I think basically GitHub still wants to create a very sort of simple consumer focus product to maximize the quantity of interactions. they're not necessarily trying to lock down and restrict all those things you know and and and provide tools to upregulate the quality of that.
I'm sure that is a misrepresentation of only a small slice of github's strategy, but anyway I think it's an interesting thing to consider. I just basically don't see them landing a whole lot of features that provide really granular controls to all this stuff because I think they'd be worried that this is going to get in the way of the sort of simple understanding of the uniformity of their product and it's going to cause too much you know confusion and raise the barriers to long tail large quantity collaboration.
I could be totally misreading them but that's my feeling about it.
The author is under no obligation at all. Of course a request is no problem. But then if that request is ignored, then that's no problem either. Who knows why there is no response. Maybe the person has other things in life needing attention. Maybe they have a bad day/week/month. Maybe they are burnt out. Maybe they have already responded to you 100x or maybe they just don't like your name.
If they do respond -- great! It's likely in their interest to respond to bug reports since it's likely in their interest to have less buggy software for themselves (if they use their own software) or for their customers (if their customers use their software). But maybe it's not, maybe they have moved on, or maybe they are just on vacation. If they are nice, then they tell you. But even that's something they don't have to do.
You are free to dislike them for that, and you are free to not use your software anymore.
You are usually even free to fork the project if you want your pull requests in and they keep being ignored or rejected. If others think like you, you get a community right away. But many people don't fork. Because it's a lot of work suddenly being a maintainer. Then you suddenly get those requests and opinions and pressure. Don't like that? See! That's the issue here! If you don't like it, then don't criticize others for not liking it either.
I think in a perfect world every request would be polite and reasonable, making what you say here objectively correct. Since this is not the case, this sadly becomes a subjective opinion.
The fact of the matter is that when one deals with the general public in any form you get all forms of good and bad interactions.
There's also an inherent asymmetry between the effort it takes for a small number of project maintainers to respond to a large number of project consumers.
There's no clear-cut answer here, but I think it is reasonable to state that someone sending requests to a project should set their expectations to match whatever licensing or contractual agreements are present in the projects they interact with.
For the most part, creators giving away their work for free don't insist that the people it's offered to accept it. A small portion of obnoxious creators make a point of insisting that some portion of people who aren't using it are obligated to use their work.
Obnoxious users are effectively discouraging, because not only does the population of users outnumber the population of open source authors by many orders of magnitude, not only also because the population of those who don't have the skills to do it themselves or contribute in a functional way is entirely contained within the 'users' category, but most importantly because each obnoxious user has only the authors of the few open source projects that they're using to be obnoxious to. Open source creators who talk about obnoxious users (usually without naming them) are often effectively criticized within the vast hordes of users.
Obnoxious open source creators are easily ignored, since there are so few of them, and they have millions (give or take an order of magnitude or two) of potential users to harrass. Open source users talk about these open source creators (usually calling them out by name), and those creators become well known as obnoxious cranks to be avoided.
After all, I wouldn't lose sleep over an obnoxious person making an obnoxious demand. They'd be summarily ignored.
But I would feel a tinge of guilt if someone made a good faith effort to offer an improvement, and the contribution was technically sound, but I just didn't get to it.
The only something there is, is what the license specifies.
Licenses vary, but generally the gist of it is that you get to use that code for free (with various limitations depending on license) and that's all you get. There isn't any something beyond that.
You're always free to negotiate and pay for a support contract if you prefer more than what the open source license grants you.
Pretty much every open source license contains a section along the lines of "there is absolutely no warranty". Older projects make this crystal clear in their readme. Newer, hipper projects don't, but that's only because they don't state it as explicitly.
Open source software is unsupported software unless you paid for a support contract. If you still get support despite not having paid for such a contract, then that support is an incidental gift that can go away at any time for any reason.
Isnt that the point? As in, it allows for the use of some (context-appropriate) open source upstream software to quickly flesh out some idea into an implementation, rather than expending time and effort writing certain code oneself (the user of the open source software). This doesn't absolve the user from the responsibility of eventually writing their own implementation, or alternatively, maintaining, that open source code/library/framework as a part of their overall codebase.
And so I seriously miss the point of where the managing or maintaining of some open source code, to satisfy some other downstream project's requirements, is the responsibility of upstream... again, when downstream uses it they do so to benefit themselves by not having to write or maintain that piece of software, but that comes with risks along with the relevant benefits. As in, its a "dependency" (in the name) for a reason.
I almost see it as bordering on a concept of entitlement to think that someone else (eg the original creator of some software) should spend time and effort fixing issues or adding functionality that benefits some user. Basically, one should always be considering that dependencies at the time of pulling them in are static and provided as is with no contract of maintenance, and that it might provide benefit currently but that there is a very real potential cost to using it in the future.
That's exactly what it is, exactly how it says in the license:
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
All software is "unsupported software" unless explicitly stated otherwise. Just because some software has its software published under an open source license does not make it magically "supported". Not more than any proprietary software.
If you want support, pay for it. You can already be glad that somebody published the source code under a somewhat permissive license (i.e. not just an illegal leak). They have their reasons. Don't just assume a "support for free model", since that assumption is most certainly incorrect.
The reason that people support their open source projects _anyway_, and _for free_ is a mix of (1) self-interest, since I want my software to not have bugs, so of course I fix reported bugs, otherwise I may run into them myself, (2) fun, since it's just fun to tinker with things, (3) business interest, since showing support makes me look good to potential customers and (4) misconceptions on the author's side, thinking they have an obligation, fueled by threads like these.
Reasons (1)-(3) are fine. Reason (4) is terrible and I wish it would stop.
Software rots, and you generally don’t want to adopt a project that is not having basic maintenance being done.
Nearly all open source software is by definition unsupported (read the license).
If you need support you can pay for it (and in the blog the author specifically states they are open to communications regarding paid consulting work).
Exactly. When your colleague wants to write new code in your repo you do a code review. When a stranger writes a large amount of code shouldn't you also do a code review?
I write Go apps and deploy them in the cloud. I haven't done a code review of Linux, Docker, Kubernetes, or the Go standard library. When an independent person puts out a library that I'm going to depend on, yes I'll review its code first. When I'm building on something that's backed by a big company (Google) or solid foundation (the PSF) then rather than reviewing the code, I'm more likely just to review the interface and docs. There's a continuum of possibilities in between. Different people may rationally draw the line where they'll do code reviews at different places on that continuum.
It is very specifically unsupported software! Read the license, it's right there in a legal document clearly spelled out (for many licenses, anyway).
> After reading that, I would not use it without completely understanding the code as if I had written it myself (and maybe that's what you should do for every dependency anyway).
A good phrase is that importing an open source library is like adopting a puppy. Sure you get the initial code for free, but all the work and mess from there on it's all on you.
Yes, if you want to rely on an open source library for production you do need to understand it as if you'd written it yourself! I know this principle has been lost in more recent times, but it remains reality. If you don't, you're just gambling on the hope that it'll work out. It can, but it's a gamble.
If you need more certainty, pay for a support contract with SLAs.
They specifically welcome requests for professional support.
I just want to add to this: Finding and training a new good maintainer is a lot of work. If you just pass the project along with its reputation to whoever comes up then you might be doing more harm and it might be better to not do anything and have the new maintainer earn their own trust with their fork. So yeah, having open source developers to pass on the project when they want to quit is not a fair expectation.
The default answer is: No. There is no support. And that's written in the license already.
Announcing anything beyond that is called an ad. It may be a useful ad, but it's still an ad.
(Assuming it's paid support. If it's support "for free" then that's part of the problem if it's social-pressures somebody to do this in their free time. You are externalizing your business support costs. And you really want to build your business empire on a teenager's hobby project? So, whoever is interested in this "intention" metadata should only really care about paid support, and then that's an ad.)
The default expectation should be that there is nothing promised beyond what's in the license. Anything beyond it needs to be clearly stated, but in the absence of any such statement, don't assume or expect anything.
Note that this expectation is clearly stated in most FOSS licenses. Usually right at the top, IN CAPITAL LETTERS. Having to write an extra blog article that basically says "I really mean what is in the license" is redundant, and it's sad the this has do be done and is even being argued about.
> This software is provided 'as-is', without any express or implied warranty.
Almost all open-source licenses will have conditions like this, MOST EVEN MAKE IT ALL CAPS. The default expectation of support from the author should be 0.0
Yeah. And I eventually came to realize: lazy.
> Yeah. And I eventually came to realize: lazy.
Lazy is just one side of the coin. If someone's career is focused on unsexy hard work instead of halfheartedly "demonstrating value", the core problem is not that they cannot slack off. The core problem is that others can hold them hostage.
That's a neat observation. My theory -- hard to prove -- would be that if you leave the code open for long enough (regardless or not of whether you pay attention to contributions, and how many of them there are), you'll find some keen soul further down the road who finds and repairs some kind of compatibility issue, security/privacy problem, or similar.
> So few users care if a project is open or not that they can safely be ignored as a rounding error.
I can near-guarantee that for users who understand that software can do whatever it wants on their system, within the capabilities of the runtime environment and as instructed, then when those users are provided with the option to be able to see the corresponding code or not, they'll choose to have it available to them. In an enterprise context: it can sway vendor selection.
That's an increasing percentage of users today, I think. Perhaps it was the case a decade or two ago that people thought of software as windowed applications on their desktop; nowadays I reckon that more people have software developers within their extended social networks, and from that exposure they have a little bit more of a sense for how computers and code work.
And in response to one of your parent comments:
> I didn't like that view of myself, so I stopped opening my software.
Totally understandable. Don't forget the fact that you have an opportunity (not a responsibility, by any means) to teach and share code with current and future generations of developers.
They might discover some relevant snippet of yours through code search and find exactly what they need to solve a problem. Perhaps they'll credit you; perhaps they won't (perhaps they won't realize or be in the mindset that it's worthwhile (and/or important) to credit people for their work) - either way you'll have helped someone with their day.
People can figure out how to build it if they want, it's not your problem or responsibility unless you want it to be.
See Keybase or Signal for instance.
Try sending an email to Linus Torvalds if something with the Linux kernel is not to your liking and you'd like him to change something. Brace for impact. Well, at least with the "old" Linus. He calmed down a little recently.
"Yeah, but what if other people contributed?"
It's a huge chicken-or-egg problem.
At this point, unless you have a big name behind you (being a major corporation like Google or Facebook, or OSS celebrity like Torvalds), the chances of any particular project growing beyond single-maintainer are really slim.
I've seen several people, on my own projects and others, talk about not trusting single-maintainer projects to last as a reason to not get involved. It's infuriating, because it's a self-fulfilling prophecy.
And there are no guarantees the major OSS names will perpetuate their projects any better than an independent, no-name, single-maintainer. If anything, I've seen companies like Google drop projects much faster than I've ever done in any of mine.
People see the name and assume there is already support behind the project. Yet often the projects start as a single-maintainer thing that the company then puts a marketing machine behind.
I had a project years ago that was my first promising open source project. It was growing, it had a small handful of minor-but-meaningful contributors. People saw my name on 95% of the commits (I was working on it full-time) and called it single-maintainer. A year after I released, a major corp announced they were releasing a competitor. They hadn't released it yet, just announced. Overnight, I saw interest in my project dry up. It took another year for that other corp to actually releases, during which time they had fewer actual contributors than I had. When they did release, it took another year before they reached feature parity with me, but by that point it didn't matter. They had started telling people they were the first such project ever. Randos online started accusing me of copying the other project. I couldn't keep up with development and marketing on my own, especially after the digital agency I was working on it at went belly up.
I knew most of the people on the team at the major corp. We were in a very niche industry and we all knew each other. I think it was that "ours is the first" bit that really got my goat. They not only knew me and knew about my project, they even admitted they had been using my project for testing compatibility of another project they develop.
Thus I now hate Mozilla with a passion.
https://en.m.wikipedia.org/wiki/Number_sign
A few decades ago, it was very common to see at the deli counter, in the handwritten prices on signs jabbed into lunch meats and such. And on the price signs above the vegetable bins at the supermarket. In the US, anyway.
But it's not your right to demand anything from a project, including demanding that they do basic maintenance or disclose whether they are going to do it. Maybe they don't even know, or maybe they change their mind lots of times ever year or every day. If you don't get a promise of this happening, neither assume anything nor start to demand it.
(Even if you get a promise, if it's some individual writing something on the net, it's not worth much. If they fail doing it despite the promise, they are being idiots, which they are free to be, and you are free to ignore them going forward or be angry.)
The attitude that published open source software is generally expected to be supported with basic maintenance is bad. It burns out creators who also believe in this myth and it creates an atmosphere that fosters this and in the end, less software is placed under open source licenses because people feel that that would include some obligation after. It does not. Just because you find some piece of code on the internet does not entitle you to anything.
It’s also pretty straightforward to disable issues in GitHub and ignore all the noise.
Just look around this thread, you can find the described attitude even here.
The contributors aren't entitled to the time of the maintainers.
Now the project someone chose for its high amount of free unguaranteed support goes off a cliff of no maintainer..
In my experience, I value projects with minimal maintenance over years by a large number of more selfishly invested contributors over the "excited just to be here" projects.
The way Github e.a. use forks dilutes the larger meaning of the word, that's what this thread is about. When people used to talk about forks, they always mean a community fracture over differences of opinion: gcc vs egcs, xfree86 vs xorg, ffmpeg vs libav, openwrt vs lede, glibc vs eglibc, kde4 vs trinity, gnome3 vs cinnamon vs mate.
The common-use term of "fork" on github has nothing to do with divergence of development, it's just a band-aid for lack of contributor access control. I can understand why people don't like github's use of forks, and that has nothing to do with what the license "allows" or not: if it's not a divergent development line, it's not a fork, it's a clone at best. In most cases, I'd say it's just a feature branch hosted in a different repository.
Calling something a fork implies long-term viability (or at least the intention) as an alternative to the original repo. That doesn't sound like a realistic description of most cloned repo's on Github to me.
More accurately: it's a consequence of GitHub's early decision to reject the traditional currency of open source (patches) in favor of imposing dark pattern-infested workflows on hosted projects and their contributors.
When you accept patches, anyone can easily create an account, submit their patch, and then be on their way. GitHub's opting for an unnecessarily heavyweight pull request workflow instead, though, meant that contributors were required to set up a personal on-GitHub copy of the desired repo, point their copy on their local machine at that as a remote, and push to it. At that point, they're already paying the cost of project hosting overheads just for contributing to a project that isn't theirs. When it comes time to start their own project, or evaluate whether it's worth it to continue hosting their existing projects elsewhere, pressure to choose GitHub cones into play that wouldn't otherwise if there were a level playing field. Fast forward nearly 15 years of network effects, and you have it as a nearly unavoidable multi-billion dollar behemoth.
It's such a transparent growth hack inspired by the underhanded tactics used by social networks that folks' unwillingness to even acknowledge its negative impact on productivity and privacy is really infuriating—not to mention the negative impact itself.
Making their code useful to other people is a strong motivator for many altruistic open source developers.
The purpose of getting PRs accepted upstream is so that your changes are useful in concert with other people's changes, especially their later changes.
Your private change is of little use to others when it's only in your private fork, which hardly anyone knows about, and if they do know, your change is incompatible with later work and maintenance by other people anyway.
If you don't care whether anyone else uses your work, especially in future, that's fine. But if you want it to be more useful to others, getting it merged upstream makes a huge difference to that.
(Merging upstream or just submitting PRs that don't get merged also helps personal visibility and reputation, which is undoubtedly a motivator for many. That's a burden on upstream maintainers when someone is pushing low quality work and doesn't care to ensure it's useful to the project.)
> You don't need to push to the original repo because open source allows you to make your fork available to others.
This is simply not true - not all open source software is copyleft. You can have restrictive licensing regarding use and/or distribution and still be open source.
Well, of course you can adopt any definition of "open source" you want, but I'm using the OSI definition, which states:
"The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software."
You are referring to "source available", for which they offer the clarification:
"Open source doesn't just mean access to the source code."
This was back in 1999 - it's been over 20 years and "OSS" has only been muddied further and further to mean "source available" since.
Pedantry aside tremon's response sums it up well: "Feature branch hosted in a separate repository."
"Source available" does not mean anything about a license at all. It literally just means the source is available... to someone.
Open source generally means it must have a license that allows modifications and derived works. It is more than "source available" it means that a public license to use and redistribute the software is available. "source available" does not necessarily mean you have a free license to use or distribute the software, or modify it and distribute the modifications. "open source" does. The Open Source Institute has tried to standardize a definition. https://opensource.org/osd
"copyleft" is sometimes used to mean something more than some "open source". Richard Stallman has promoted these sense of "copyleft". Like GNU license as opposed to apache. Both are open source -- nobody says apache license isn't open source right? Open source licenses that aren't "copyleft" are sometimes called "permissive". Here's one description of it that will suffice:
> 3. Is the Apache considered copyleft?
> Copyleft licenses require the derivative works or modified versions of existing software to be released under the same license. The Apache License doesn’t have any such requirements. It’s a permissive license. It permits you to release the modified parts of the code under any license of your choice. However, you are required to release all the unmodified parts of the software under the same license (the Apache License).
--https://www.whitesourcesoftware.com/resources/blog/top-10-ap...
So, no, "source available" is definitely not the same thing as "open source" -- all open source may be "source available", but things described as just "source available" usually are not open source. The source might be available to you, but you might not be allowed to use it (at all, or in certain ways) without paying, and you might not be allowed to redistribute derived works.
And "copyleft" is usually used as a subset of "open source", for restrictive/"viral" licenses.
I have no idea what any of this has to do with where this discussion began -- but yes, anything that's open source, copyleft or not, gives you the right to make a variaton of the software, use that variation, and distribute it. I think that is part of the accepted definition of open source. "Source available" software may not give you this right.
Maybe it is time to ditch both "open source" and "free software" and go with something that has a clear meaning that isn't possible to muddy, like "libre software", prefixed with "always" for copyleft licenses and "currently" for permissive ones.
https://www.gnu.org/philosophy/open-source-misses-the-point....
The important bit is here:
> “Free” and “open” are rivals for mindshare. Free software and open source are different ideas but, in most people's way of looking at software, they compete for the same conceptual slot. When people become habituated to saying and thinking “open source,” that is an obstacle to their grasping the free software movement's philosophy and thinking about it.
I have seen "FLOSS" used as an umbrella term for ALL of it, that is anything that is open source is also "FLOSS". But you are saying it exists to differentiate from "open source"? Huh. Just to muddy the waters yet further.
To quote Bruce:
> Most hackers know that Free Software and Open Source are just two words for the same thing. Unfortunately, though, Open Source has de-emphasized the importance of the freedoms involved in Free Software.....
> ......Sadly, as I've tended toward promotion of Free Software rather than Open Source, Eric Raymond seems to be losing his free software focus. The Open Source certification mark has already been abused in ways I find unconscionable and that I will not abide. I fear that the Open Source Initiative is drifting away from the Free Sofware values with which we originally created it.
There would be no need to make any kind of distinction between Free Software and Open Source if Open Source was being perceived as Free Software.
OSI was and always will be a marketing gimmick [0] created to sell the idea of open source to commercially interested parties.
> We realized that the Netscape announcement had created a precious window of time within which we might finally be able to get the corporate world to listen to what we have to teach about the superiority of an open development process. We realized it was time to dump the confrontational attitude that has been associated with `free software' in the past and sell the idea strictly on the same pragmatic, business-case grounds that motivated Netscape. We brainstormed about tactics and a new label. Open source, contributed by Chris Peterson, was the best thing we came up with.
Not to downplay OSI at all. It was extremely important and widely influential in Netscape's journey to becoming Firefox and I'd even argue is still important today. But the issue centered around what "Free" means ("Free" as in freedom - not beer - which is why the term "libre" is often used as well) and that "Free Software" already had a poor reputation in the business world and so it needed to be rebranded. Eric Raymond made it very clear that he places importance on phrasing and branding and attributes the tactics used by OSI to its success and why the Free Software movement failed. [1]
Honestly a comment by Havoc Pennington on that very post, dated Jun 28, 1999, sums up the issue perfectly.
>I think Eric's analysis of the facts is basically right. i.e. the "open source as business" stuff has gotten us a lot of popularity. The danger is that we fall for our own marketing program. That is, new community members join, and we have to say "we didn't really mean that. Really we meant freedom. The business stuff is for the suits." An increasing number of new members just don't understand freedom, or copyright, or anything like that; they joined "Linux," not "GNU."
[0] http://web.archive.org/web/19981206185148/http://www.opensou...
[1] https://web.archive.org/web/20170630183629/http://www.linuxt...
See the "Common Misunderstandings of “Free Software” and “Open Source”" section of the article I previously provided. This is a known issue by both OSI and FSF.
> Ask anyone who is not already heavily involved in open source software development [what "open source" means]
Where's the shock? Asking anyone about something that they're uninformed about and expecting an informed response is silly.
The Free Software Foundation disagrees that "Open Source" and "Free Software" are the same thing. The discussion about whether they are the same thing should end there if we are to accept that the authority defining "Open Source" are correct in their definition of "Open Source". The same credence should be given to the authority defining "Free Software" providing the correct definition of "Free Software". If we are to accept both of these definitions as given by the authorities defining the terms - then they are necessarily different because the authority defining one of the terms says so despite any attempts of another authority who did not define the term at claiming otherwise.
In other words: X defines X and says X = X and X != Y. Y defines Y and says Y = Y and Y = X. Since X defines X and Y does not define X we must accept that X != Y per X's definition of X despite Y's attempt at redefining X such that Y = X.
It's uncharitable to point to OSI's definition of "Open Source" and OSI's claims that they are one and the same while completely ignoring FSF's definition of "Free Software" and FSF's claims that they are different.
No idea about cancer, but even just on HN there is confusion about which meaning of "sustainable" is being used and what environmental and other impacts each energy technology embodies.
I think most lay persons, upon being informed of the existence of a "Sustainable Energy Initiative", would readily admit when pressed to a lack of sufficient familiarity with the subject that would allow them to answer with confidence about what does or does not meet the standards of being deemed "sustainable energy". Likewise with anything involving "cancer"—most people cannot define it.
But this is beside the point, because we're not talking about the work activity of the OSI. We're taking about the definition of "open source". This is not the first instance of your moving the goalposts in this discussion.
> The common misperception regarding "Free Software" is that people think it means "gratis" rather than "libre". The common misperception with "Open Source" is that people think it means "source-code publicly available".
Right. The key thing being that those are misperceptions.
Misperceptions about the distinction between "cancer" versus "viral infection" versus "bacterial infection" would not lead us to say that because the public does not have a good understanding then the definition of "cancer" changes to something that it isn't.
> if the argument about common misperceptions being muddied water is not entirely convincing
That's not what's at issue.
> The Free Software Foundation disagrees that "Open Source" and "Free Software" are the same thing.
The FSF agrees that the definition of "open source" is the one that was formulated at the end of the last millennium; the FSF doesn't disagree with the OSI about the definition of "open source".
We started with your claim from the ahistorical definition of "open source" that a given project may not actually permit people to make their fork available to others. Any argument you make here needs to support that.
So far, you're making a lot of facile "water _is_ wet*"-style observations and, I dunno, hoping that no one will notice that that was never the point of contention.
* Try substituting "FSF was founded in 1985" (or any other factual statement) here that while true nonetheless has no bearing on the actual substance of the current dispute, despite whatever surface-level relevance it may appear to have to someone who is only halfway paying attention.
How people use words matters almost as much as what those words mean - and meaning can change because of how people use words over the course of years, decades, or centuries. Pointing at a dictionary is only useful when clarifying which meaning is being used.
> That's not what's at issue.
Then what is the issue, if you don't mind me asking? The issue as I understand it was what was meant by "open source" and my not already prescribing to the OSI's definition of it. Pointing to the OSI's definition cleared the air about which definition was being used but did not resolve the issue that the phrasing is easily misunderstood outside of the OSS community and is the reason the term "FLOSS" exists to circumvent the issue. The fact they had to specify the definition as defined by OSI and not "source available" is part of the issue. That this misperception exists at all is part of the issue. That the OSI has had to plea with people to please use the branding how they want it to be used [0] is part of the issue. That it is not totally uncommon to see "open source" to only mean "source available" is part of the issue. That "open source" has an obvious plain-English meaning separate from it's "intended meaning" is part of the issue. This is an issue that has existed in the community for the entirety of its 23 years of existence, been spoken about at length by both the OSI and FSF as being an issue, and some people are acting like it's the first time they've ever heard about this being an issue or even denying that it is an existing issue at all.
I'm not sure how many articles from community leaders and the very people who defined the words in the first place speaking about the issue being an issue I need to cite before people go "OK maybe it is an existing issue and not just Nadya saying it's an existing issue when it isn't."
To actually and intentionally move the goalposts this time: It still isn't even logically sound that because you're able to fork and send a PR on Github that the project is "open source" to begin with and it especially doesn't follow that the project is compliant with OSI's definition of "open source". Per my understanding of the Github Terms of Service Section D Parts 4-7 the license given to other users only extends so far as to their using Github's functionality (including "forking") - which I'm reading as not providing any license to compile or redistribute modified source code compiled into an executable. Making sending a PR possibly the only reasonable method of ensuring that a fix or feature makes it to end users.
It might be time to start using more descriptive sentences like "source code available under a proprietary license" or "libre software that can be made proprietary" or "software that is perpetually libre" instead of the "Free Software" and "Open Source" terms.
I agree it is still a problem - which is why "gratis" and "libre" see use to prevent the confusion and why I prefer the term "FLOSS".
This is a big misconception. The Open Source Definition requires source code, you can't have an "open source" project that just releases binaries under the BSD license for example. The OSD (and the Debian Free Software Guidelines that the OSD is based on) is about the software and its attributes, including both the source code and the license.
But I'm still entirely wrong.
I'm completely and unequivocally wrong due to two other requirements - both of which actually pertain to the source code and not its licensing. There are in fact two requirements placed upon the source code itself to be considered open source under the OSD or even as free software as the FSF defines it. (1) It may not be deliberately obfuscated. Which makes me wonder if programs written to be deliberately obfuscated are technically not allowed to be considered free-libre or open source software? Such as programs written to compete in IOCCC or if the intent here matters and it's more about releasing obfuscated versions of source code that was not already written to be obfuscated and was made obfuscated with the intent being to prevent others from studying/modifying it. That one I think is a bit of a technicality. (2) The other being that the source code, if not released with the program, must be available in a well-publicized manner at no more than a reasonable cost of distribution/reproduction (ie no charging $1,000 for access to the source code to claim it's "technically available").
> freedoms afforded by FLOSS licenses necessitate the availability of the source code
This isn't really true, security researchers, reverse engineers and piracy experts often do the equivalent of the FSF four freedoms without having the source code. Of course not having the source code makes it harder for people without those skills and without the often costly proprietary tools that enable this work.
It is possible as a technically skilled person to write a binary in machine code, without any assembly or "source code" or other primary format. When an FLOSS license is applied to that binary, it should be considered Free Software. An example of this is the hex0 binary of the stage0 project, which is the first piece of code run by the Bootstrappable Builds project, which aims to build an entire Linux distro starting with only the ~512bytes of machine code in hex0 plus all the necessary source code.
https://savannah.nongnu.org/projects/stage0/ https://github.com/oriansj/stage0 https://ekaitz.elenq.tech/hex0.html https://bootstrappable.org/ https://github.com/fosslinux/live-bootstrap/blob/master/part...
> Which makes me wonder if programs written to be deliberately obfuscated are technically not allowed to be considered free-libre or open source software?
Debian definitely rejects such software, I assume the FSF/OSI would too, although they mostly concern themselves with licenses rather than actual software projects. In the past at least 3 times in different FSF/GNU projects, the FSF/GNU project has caused downstream GPL violations due to releases that were missing source code. Even minified JS without the original JS is not considered DFSG-free by Debian, even though it is extremely common these days. Debian applies this rule to all digital files, no matter whether they are programs or fonts or images or videos or other things. Some articles related to this topic:
http://www.inventati.org/frx/essays/softfrdm/whatissource.ht... https://b.mtjm.eu/source-code-data-fonts-free-distros.html https://wiki.freedesktop.org/www/Games/Upstream/#source http://compliance.guide/pristine
> programs written to compete in IOCCC
The main thing about source code is that downstream users be afforded equality of access to a work as the original author of a work. So if you can write an obfuscated program and realistically modify it yourself without hiding the real source code from users, then that is considered fine from the source code point of view. Of course it is a terrible way to write a program and should get modified to de-obfuscate everything, so more people can understand the code.