I'm the creator of a just-mildly popular OS project (~700 stars on GH) and I had to give up being the main maintainer. Too many "issues" were just people who couldn't debug their own code, or "issues" where the person would describe some weird edge case but be unable to provide any example code. After enough of those, and getting busy with other things, I just couldn't keep up with it.
Luckily, one of the contributors stepped up and is now the main maintainer. I still read through the issues that come in and he does a great job of responding and keeping cool. I don't know how he does it.
I was contributing to more popular projects, between 2.5k to 4k stars on GH, I just gave up and stopped doing it for free when users just open issues like 'I requested this feature 5 months ago and it's still not implemented. what are you waiting for?', after reading 8th of such issues in 3 projects I just left all of them the same day and started working on my commercial project. Working on OSS where every idiot can open an issue for free and complain or think we're their slaves if waste of time and energy. Never. again. The worst were users or forkers who asked me to change license of a project from MIT to GPL because they would like it more... eh.
A maintainer of an open source project, or really anyone who has a public-facing role online, needs to develop a thick skin and be able to ignore griefers and trolls. Ask anyone who works retail or customer support how horrible people can be. Now multiply that by 10 for people online.
A pretty good example of this is the recent opening of Fallout 4 mods to Xbox users- almost overnight mod makers were spammed pretty much everywhere with demands to stick it on xbox, do this, do that, etc. Lots of bad blood.
Did it once. Closed an issue I couldn't reproduce and author didn't want to show me their code. I got blamed for not helping them and not fixing problems in my code :) I stopped responding to such issues at all.
I maintain Cachet [1] which has 4.4k stars on it. I've closed several issues in a similar vein, only to be ranted at for not giving a reason. I shouldn't have to explain the same reason for the fifth time when you could've searched for it already — but hey, I appreciate the thoughts.
My experience, having locked a thread exactly once after triaging several thousand reports on TypeScript, is that you immediately get another bug from the same person complaining about how dare you lock an issue.
Maybe the solution is to use an issue tracker outside of GitHub. It seems like a lot of these problems come from how easy it is to make drive-by comments without really being involved in the project's community.
I moved to GitLab where I can disable issues completely or allow only specific people opening issues[1], unfortunately most projects are on GitHub. It also discourages lazy (who are usually useless) reporters from opening the issues, as they would have to create new account, 2:0 for me.
Altassian JIRA (cloud or self-hosted) is free for Open Source projects. You can add as many required fields as you want and make creating issues as complicated as necessary :)
This actually makes me wonder if open source is the right thing for many projects.
For a project that other engineers will use it seems to make sense. Other engineers (or some percentage of them) can contribute.
But certain projects really target non-engineering types. I don't mean that in any judgmental way. Only trying to distinguish between those who will need a ton of hand holding and are unlikely to contribute back and those the have a higher percentage of contributing directly back the the project.
Off the top of my head the creative coding community is full of artists who've learned just enough code to be able to glue things together and make cool art but not enough to contribute to the things they are gluing together. They generally fit the profile of "starving artist" or student.
The game dev community is also going that direction because several projects have made it simpler to be able to create a game with very little programming skills.
I'm not sure what my point is other than if you make one of those types of projects you're going to get pleads for help from people that probably can't construct a pull request. Not sure how to fix that.
> This actually makes me wonder if open source is the right thing for many projects.
This is why the term "open source" is confusing, and I'm annoyed when people use it. If you're referring to software freedom, free software is necessary for a free society. If you're referring to the bazaar model of development, then I agree that some projects don't need to work that way. What's important in free software is that there can be a community of users, but it doesn't matter if the original developers decide to be part of that community.
I wish GitHub had a "close in one week unless there are further comments" button. Maybe make the time adjustable.
That way, if someone submits an inadequate bug report you can ask for more details and then tell the ticket to auto-close if nobody responds in time. I'm sure you could do this with a 3rd party tool and the GitHub API.
I liked Github's new feature that prefills in the New Issue with the instructions. Maybe that cuts down on poorly specified issues?
Separately, was there ever demand for charging for non-standard support, a la Red Hat? I don't mean for those highlighting bugs, but for people who wanted more basic help. The world needs more open source and open source developers, and I wonder if models like that are both compatible with OSS and provide some support resources for the developer.
Anecdotally, we added a template to the TypeScript issue form.
Our stats (duplicate / not repro / just a question) didn't move at all. Our template had a sample version number in it that the logger was supposed to replace with the actual version number; that nightly-changing version number exists in 63 issues.
People still log bugs with literally identical titles to existing issues. People still log bugs with repros that don't display the behavior they're describing. People log bugs that are obviously just questions, which the template asks them not to do.
I don't think there's a fix here. Fundamentally you're asking someone to do work that they can, at no social cost, offload to someone else. I would love to try a model where it costs $1 to log an issue and the maintainer can give you back the dollar at their discretion.
Tim is doing an absolutely marvellous job managing releases, reviewing pull requests, and a plethora of other work. Any Django user who can afford it (and especially companies that profit from Django) should think about donating to keep the Fellowship going. It's a great investment.
Having maintained an Open Source project for almost 20 years now, there are some ways to deal with bad users.
One is to not take it personally. Annoying people should get ignored or banned. They're just not worth the effort.
Two, is to recognize that your time is limited. If the person filing the bug can't (or won't) help track it down, well... too bad. Maybe no one else runs into the bug, and your best response is "works for me". (Note that this is the approach taken by most commercial software vendors in my experience)
Three, is to recognize that there are idiots out there, and you can't help them all. It's OK to be on the lower end of the bell curve, but sometimes it's like the kids rides: "You have to be THIS TALL to go on this ride". If the user can't comprehend something, perhaps he shouldn't be using it. And perhaps you shouldn't waste your time trying to get him to understand something he just can't understand.
My general approach is to be nice to people who ask good questions, and who try. When people ask terrible questions, and make it clear that they have no interest in lifting a finger, but demand that you do all of the work... well... they get told in no uncertain terms to shape up, or get banned.
You don't owe these people anything. If they had an ounce of human decency, they would understand that they got the software for free, and that they don't deserve anything. And that they need to put some effort into it on their end.
The main response I have with these people is If you're too lazy to help solve the problem, then I'm too lazy to help, too.
I maintain UI Bootstrap (over 12k stars on GitHub), and I have to make decisions on bugs and feature requests. I prefer erring on inaction of response if I am not sure of how to decide, and I make it a policy to close support issues on the repository.
Ultimately, if someone really cared about a particular issue, the person would make an attempt at a pull request to help contribute. I will even often help give most of the important abstract information needed for a contribution too to assist in the general implementation, but I can only do so much work for people.
I am also inclined to help bad attitude people the least - it is the quickest way for me to take longer to reapond & implement, so be nice to your friendly open source maintainers people!
Having the necessary skills does not mean they cannot make an attempt though. If they regress into whining instead of trying, then I'm less sympathetic & less likely to put my best effort forward since it's unnecessary stress.
Really? I might be able to report a bug in any number of roles (perhaps designer, perhaps administrator, perhaps user) and I may not have the knowledge or experience necessary to fix the problem, but certainly enough to report in a detailed way. If knowing software development is not my job, I can't be a user? What if I am a developer but not familiar with the code?
Dismissing users because they do not have the skills to fix every problem is absurd.
I'm not dismissing the users, I'm just saying that nobody owes you a bug-fix. If they prioritize your bug, that's great, but if they don't - either submit a pull request or live with it. The knowledge developers put towards their free hobby-projects is hard-earned and shouldn't be treated like public property.
An understated problem here is that opening an issue to create a "feature request" is seen by Github as a "contribution", one on par with actually fixing bugs.
We've got people going around opening hundreds of issues for silly things like variable names in products they don't even use, presumably with the aid of some bot.
Nearly everything written in C or C++ has had a issue requesting the build system use autoconf, an issue requesting the use of CMake and a issue declaring scons is the best. Even if you liked all these tools, it would be absurd to satisfy all three requesters.
None of these people are "contributing" in the way someone fixing a bug is.
That's essentially what "Works For Me" means. Generally, the dev would ask for reproduction info, and if it can't be reproduced by them using the information supplied (maybe after a few passes, and after investigation of environmental differences), that's the proper way to close the ticket.
Could you charge for support? Can you offer consulting services?
H2 (h2database.com), one of my favorite projects, accepts donations.
A close friend created a reasonably popular web framework. Books, conventions, etc. He got some good consulting gigs and paid travel. He regrets he didn't pursue that more (others stepped up to fill the void).
none of my users could afford what I'd have to charge to make it worth my while.
If some corporation with deep pockets needs support maybe they can pay but the majority of people that need support seem to be people that need everything to be free (noobs and students).
I spent a few hours the other day trying to troubleshoot a problem with a Compiz interaction on one of my machines causing high temperatures at lock-screen. I finally found that the problem had been intermittently reported for the last 2-3 years without much traction in finding a solution.
My solution? Bypass that lock screen. It's not an issue for enough people to be worth me bothering them about it, if it was then it would have a fix already.
I've closed two github accounts (and 4~5 related projects on each) because, well, all the stuff you say. I'm happy to toss something out there, documented, and let people do with it what they will - but supporting stuff in someone else's use case is not part of my agreement with the universe.
Apart from being notified with an email or similar when a new issue has been created, what other annoyances does a maintainer have to deal with? I mean, is the number of open issues raising what annoys you? or is it for not being able to keep organized the issues?
I have a project of medium popularity (~4k stars on github). A lot of the annoyance comes from _bad_ issues, or pushy people that want to know why X is done Y way -- after all, only morons do X _y_ way, or just answering the same questions over, and over, and over.
Something like 70% of every issue/email I've ever received could easily be auto replied with "please provide version, platform, code to reproduce, etc.." the number of people that will post an issue that just says "it doesn't work" or "how do you do X?" wears on you after awhile. The open issues for a medium sized project are (I consider) a metric of the project's overall health. So, if you want to keep your tracker clean, you've gotta put on your administrative hat and spend time grooming things, which takes an energy toll. Developing is fun, fixing real issues is fun, repeatedly teaching people how to ask a useful question is not fun.
Also, pull requests can be the most stressful of all. People are extremely entitled about pull requests. The number of reasons why something might not get merged in right away or at all is _massive_ (and often simple: I'm busy). However, a lot of people seem to take it as personal attack that their glorious work was not immediately commented on/reviewed/liked/pulled/etc..
All of that can add up to a lot of stress around a project from which you draw no income.
> just answering the same questions over, and over, and over.
Have you considered creating an FAQ?
> Something like 70% of every issue/email I've ever received could easily be auto replied with "please provide version, platform, code to reproduce, etc.."
Github has issue templates now. This could fix at least some of these incomplete submissions.
For me, we have a FAQ, "man" pages, on-line web documentation, and documentation in the config files. There will always be some idiot who is incapable of reading any documentation.
My personal favorite is a debugging error messages which is something like:
Failed reading file X: no permissions. Please check that file X is owned by user U and writeable by group G"
People post such messages to the mailing list about once a month, asking "What does that mean?"
There is no good answer which will satisfy them. If you tell them that the message is self-explanatory, they get mad at you for not explaining it. If you ignore there messages, they re-post repeatedly, asking "Why doesn't anyone help me?"
There's a subset of people who just shouldn't be using software.
Whoa, TIL that they added issue templates! That's pretty awesome. That should indeed help cut down on some of the administration work required when answering issues.
I wrote a bunch of code on github related to model inference. The inner loops are executed trillions of times in regular usage. Part of the value my code provides is I've spent several hundred hours going through it with vtune on different xeons. I regularly get mail saying my code is structured incorrectly or critiquing the code as if I'm a novice developer. It's very frustrating.
The most important thing about releasing free software (open source) is that you don't owe anything to anyone by doing so.
Virtually all free licenses actually codify this. If you read the SHOUTY CAPS part, it says exactly that: no responsibility from the author.
People can come and ask for you to fix something or support them or accept their patches. That's fine, and if you want to engage them, you can. But there is no obligation to do so.
Once I accepted this, the growing pile of bugs/issues/support requests on the Octave and Mercurial bug trackers become a lot less anxiety-inducing. I'll try to help, but if I couldn't... sorry, it's not my responsibility!
Is there a good reason GitHub doesn't support (issue) "moderator" roles instead of "contributors", which also gives write access? So much could be solved with better moderation tools.
This seems like a perfectly reasonable issue? I think if someone is unable or unwilling to spend time maintaining a project, designating a successor is the right thing to do.
Or are you saying that we shouldn't even have to ask the maintainer to designate a successor, we should just find one without the maintainer's involvement?
> but from his username it seems like he is the successor
That's correct, I thought it was obvious but I was trying to say that if more experienced people did this the open source ecosystem would be in a much better state.
The pull request hack saved my project. I had created an open source project but didn't have time to keep up with it, was falling behind, and hated looking at the open issues. (I imagine many of you know the feeling.)
After reading the pull request hack, I gave commit access to some people who had made solid contributions. One of them ran with it, replying to issues, merging outstanding pull requests, closing obsolete issues, and doing a great job. (Thanks z3t0!)
If you're feeling overwhelmed by an open source project or no longer enjoying it, give the pull request hack a try.
Ugh. I ended up making a bunch of contributions to a project that we were using for work and the maintainer did this. It was a headache for >1 year after we stop using it and the maintainer disappeared.
So they are also able to push directly to master, push bad changes, backdoor/add malware to your projects and make a release. I would be careful with this.
I'm one of the people who do this, if anyone is doing more significant change than just updating the readme/fixing a typo, give them collaborator status after checking out their profile.
I think the benefit of people feeling proud of being a collaborator and trust from me, is bigger than the risk of someone ruining their own reputation by adding a backdoor.
But, most of my projects are tiny-ish and not even close to big, so I guess I have a bit more flexibility in this.
EDIT: Just remembered that you can activate "Protected Branches" on Github (and I'm sure something similar exists for Bitbucket and Gitlab as well) that disables pushes straight to master.
You're not just trusting them to have good intentions, you're also trusting them to keep their system secure. If you have commit access to a popular project then your commit credentials are a high value target. What do you know about their security practices?
You're bringing back memories. I was an AIX sysadmin (among other things) when IBM added a new layer of tech support because too many issues were making it through to the developers.
You had the script readers, someone to read the man page to you, then the new layer, that I never reached because I don't like yelling and we only had 8 servers. Then, I think, you got to someone who could triage issues.
I discovered another way of getting contributors with Umbrella JS [1] (500+ stars), using up-for-grabs [2][3].
In total I'd say it's similar or even a bit more of effort per issue, however many people contribute and sometimes they step up and continue with more things.
Not sure how useful it is for projects that are more monolithic though, I was lucky with this one as Umbrella JS has many small modular parts.
A lot of those 80% projects on github without licenses are simply not meant for public consumption. Think things like bash or emacs dotfiles or class notes scribbled into a txt file or a very personal project that has no hope of working anywhere but on the author's machine. I think people overstate how "post-licensing" people view open source (née free software). For everything important, people still mostly slap free licenses on their projects.
...which is probably why it's a better idea to keep those projects in private repositories outside of Github. Yet somehow, people keep forgetting there are other project hosting options (Bitbucket, Gitlab, etc.).
> which is probably why it's a better idea to keep those projects in private repositories
Not necessarily. Public dotfiles are easy to link to in conversation, and "users" are likely to be people who just copy and paste some interesting lines. A license is probably irrelevant for, eg, vim configuration options.
Question: why people seem to be so affected by unpleasant contributors? I mean, no one forces these people to use an open source project and no one has an obligation to support it at all, yet I see articles like this popping up pretty often. What's the harm in ignoring the unpleasant contributors and focusing on the ones that provide actual value to the project?
Later in the issue, someone jumps in the discussion and trashed all over everyone. That same person hopped on every blog post, ever medium post, every discussion, gitter, everything. It was bordering on harassment. I don't maintain that project so it's easy for me to ignore, but for the people involved, it must have been pretty rough.
It's hard to block them out. You can tell yourself to ignore them, but (in my minimal experience at least) it's near impossible to actually do so completely.
In the end we're all human. You can try to ignore it, but just scanning the text is probably enough to raise the blood pressure of most people, even if you immediately block the offender. You still read it and it was still stressful.
Because you get a stream of rude, entitled, hostile people either directly emailing you or pushing notifications into your email. All for a bunch of unpaid work.
Dealing with users is nothing compared to dealing with Linux distributions.
The distribution will patch your code. You are powerless to stop this. They will add bugs. They will add ill-conceived and/or incompatible features that the users will come to rely on. Fedora adds a -Z option, and Debian adds a -Z option, and SuSE does too, and all of them are in conflict with each other and with the purpose for which you had reserved the -Z option.
I salute you, open source maintainers. You are our heroes we don't deserve. I'm pretty sure I would become a murderer if I had to deal with what you deal with on a daily basis.
Can we please stop using the term "open source" when referring to free software? Especially in the discussion of benefits of free software over proprietary software. What you're contrasting here is the bazaar model over the cathedral model (though the book itself is horrible).
There are a lot of beginners who try to learn programming by using GH. They might not know how to make an example, or how to reproduce the bug by giving directions.
When I worked as a programmer, I had coworkers and other employees I worked with who couldn't tell me how to reproduce a bug, or give example code, and I had to train some other programmers in the language to help them learn more to work with a team. You can't just WONTFIC an issue, and yes it is harder to work that way.
You cannot block or ban people who are annoying or ignorant in a corporate environment. You have to find a way to help them out, by educating them, or just trying to fix the bug as best you can even if you can't reproduce it.
I made a debug version of the program that trapped for errors, and wrote them to a log file and displayed a custom error message so I can tell what part of the program it had the error in. You have to learn how to innovate and work with annoying and difficult people who don't even know they are annoying or difficult. Yeah it is stressful, but that is the difference between an open source project on Github, and working for an employer as an employee or contractor.
This could also be viewed as a challenge to develop better tools.
For instance, maybe there is data mining to be done on issues to auto-aggregate them so that you can still make some sense of the list without manual tagging and without relying on each submitter to choose sensible categories.
Maybe there need to be open-source libraries aimed at unclogging issue systems, such as a system for in-app bug reporting.
Maybe issue-tracking systems should auto-upgrade priorities on stale issues, or auto-close them based on lack of activity from the submitter.
This is one of those articles that reminds you why we should prefer the term 'free software'.
> First, a conclusion from the 2015 Future of Open Source survey:
> “Seventy-eight percent of respondents said their companies run
> part or all of its operations on OSS and 66 percent said their
> company creates software for customers built on open source. This
> statistic has nearly doubled since 2010.”
The 2015 survey on this website was responded to by 1500 people. (0.0000002% of the population)
They don't provide numbers for the 2010 response set.
> Second, Nadia Eghbal, who is doing really great research into
> the economics of open source, calculated that “open source was
> worth at least $143M of Instagram’s $1B acquisition.”
Likely wrong, but my feeling is most HN readers aren't thinking Instagram valuation is the best way to judge the value of free software.
> I think there are a few reasons for this Cambrian explosion of
> open source usage:
>
> 1. Open source is free to use, which means a company can spend money
> on people (aka innovation) instead of software licenses.
Everything I've read in the past 15 years suggests that free software's value proposition isn't founded on capex (in fact it's probably misleading to look at these numbers)
> 2. There are now a critical mass of reliable open source
> components, which accelerates your product’s time to market.
Assertions without evidence. Plus a lot of us probably have thought a critical mass was achieved a long time ago.
> 3. Open source produces quantitatively better software.
Assertions without evidence, despite popularity of opinion.
> 4. Near and dear to me personally, open source permits
> companies to collaborate on common problems without
> complicated business agreements.
In my experience some of the most exhaustingly complicated licence discussions have been around the various free (or similar) licences on various lumps of code. At least with non-free licenced code you know nearly precisely where you stand.
> "Open source" now means two things.
>
> Clearly, there’s the official definition, a permissive
> license which grants certain freedoms to the end user.
Clearly? No citation provided. Worse yet, 'open source' was clearly a rebellion by esr against the idea of emphasising the freedoms to the end user.
Eric's related rant at http://www.catb.org/esr/open-source.html is often provided ... but read it critically and you realise there's very little of substance there, other than negating the extant 'free software' position, and a call to authority fallacy.
> But when people use "open source" today, they’re probably
> referring to building and collaborating in public. In fact,
> they may not care about the license at all — over 80% of
> projects on Github don’t have an explicit license.
80% of github projects don't include a licence ... qed ... 'open source' equates to building and collaborating in public?
> Why are so many people involved in open source? Well, for
> all of the business reasons covered before. I also think it’s
> joyful to get to work with people of a variety of cultures
> and backgrounds. Additionally, open source has given me a
> sense of permanence to my career, where the job I’ve taken
> from year to year has not.
I'm empathetic, but this sounds like a plea for help.
More importantly it precludes the more common, and nuanced, reasons that people generally provide for why they spend so much time and energy contributing to the free software movement.
The rest of the post feels a bit facebooky, with lots of 3-8 word pithy aphorisms encoded in a 1024x576 pixel image.
> over 80% of projects on Github don’t have an explicit license.
I wish more people understood that this is a bad thing. These projects are ones that every business should fear more than the GPL3. Copyright is the default in the US, not public domain. Without a license you have no right to redistribute it, or to distribute works derived from it.
I concur, and the biggest challenge I see, in this case, is the regional one you cite.
Happily it's relatively easy to resolve for 99% (a number I just made up) of these 80% of github projects that lack licences -- by either opening an issue, or emailing the author, and seeking clarification.
In defence of these unnamed persons, I suspect that if you're about to work with a project that hasn't fielded this type of query previously (and resolved it within their repo) then you're in some troublingly unchartered waters on at least two fronts.
80% of the projects on GitHub don't have an explicit license, but how many of those are actually useful, mature pieces of software that a business would want to use in production?
I would guess that a large portion of these projects are just personal projects that have little value to anyone other than their author.
> I wish more people understood that this is a bad thing.
Why is it a bad thing? If you represent a business you are free to either refrain from using the project, or send a message to the author(s) and request they add a license. Perhaps the author has no intent to allow others to use their code, and they are merely using github as a convenient place to host their code. Like you said, nobody is allowed to use their code without a license, so why bother to use a private repository?
It might be a bad thing if the author actually put their code online with the intent of having random businesses use it, but it's a bit presumptuous to call it a bad thing in general.
> Copyright is the default in the US, not public domain. Without a license you have no right to redistribute it, or to distribute works derived from it.
The absence of a written license is not necessarily the absence of a license; implied license is a thing. Determining the existence or parameters of an implied license, of course, can be difficult.
As someone who have to deal with crappy proprietary software for some of my work, all I can say is that with open source at least I can fix a problem or implement a feature that is lacking - instead of bang my head on the wall waiting for the good will of the vendor (even when I want to pay well for a hotfix).
I (and I think we all) have worked with crappy open source and good proprietary, as well as good open source and unusable proprietary software. But one thing you said stays true: "at least I can fix a problem or implement a feature that is lacking". And I think that is the main reason people stick to open source.
And I think that it's the main reason why some open source projects remain so crappy: main contributors are mostly interested in development of cool new features and users are treated as both beta-testers and maintainters, and are expected to find and fix bugs themselves.
> And I think that it's the main reason why some open source projects remain so crappy: main contributors are mostly interested in development of cool new features and users are treated as both beta-testers and maintainters, and are expected to find and fix bugs themselves.
If these projects were crappy no one would bother using them.
You're not entitled to anything as a user of open source software. Open source is about collaboration, not entitlement,it's not one dev having to maintain everything for other developers.
> open source is about collaboration... you're not entitled to anything as a user of open source.
It is true.
However, this is why Proprietary software will always be around and why there are many markets where Free Software won't take over. There are many people that don't want to be a collaborator because they don't enjoy dealing with software. They just want to exchange money and have a problem solved for them.
Free Software is, for some people/organizations, more expensive than proprietary software because they would need to hire somebody to solve their problems. You're right that they aren't entitled to someone else's labor for free. However when they pay someone's salary (by buying proprietary software, or a support contract), they are entitled to something: as much support and hand-holding as they can negotiate for given that they have the BATNA of paying a different company. For people/organizations that need that hand-holding, it is necessary to make some tool useful at all, so it ought be considered part of the cost when telling someone "you should use Open Source! It is Free as in Beer!" If you think that those folks are wrong about the cost of Free Software, then either tell the sales folks at Red Hat or do the arbitrage yourself.
Ive seen arguments involving someone advocating Free Software for economic (rather than ideological) reasons and just not getting it, so I apologize if I sound like a broken record.
(oh, and a tool can be useful enough to work, but crappy enough that it makes someone feel frustrated and stupid while using it.)
>However, this is why Proprietary software will always be around and why there are many markets where Free Software won't take over. There are many people that don't want to be a collaborator because they don't enjoy dealing with software. They just want to exchange money and have a problem solved for them.
So, uh, while it's certainly true that it makes a lot of sense to exchange money for goods and services, in this case, working software, my experience has been that a lot of times? proprietary software is worse at this than open-source. See RedHat, for instance, for an example of pretty good support (well, compared to what you get when you pay money for proprietary software)
In fact, i think there are structural reasons why buying support from someone who supports an open source product might be better than buying support from a company selling proprietary software. The main reason being that the open-source software provider has competition. People other than RedHat can reasonably support RedHat software; this can't really be said for closed-source software.
Considering the huge pain in the ass that switching business critical software packages usually is, well, my personal experience is that if you get something closed-source from IBM, you are going to be way more disappointed in their support than if you get something open from RedHat.
I don't mean to argue wholesale against F/OSS, but against a certain approach to it. You are absolutely right that there are some domains where the Open Source software available is much better than the proprietary software. <insert rant about oracle's developer experience compared to PostgreSQL>
Another related structural reason is the lower cost and lower risk for a professional of educating oneself on open source, reducing hiring costs. This only applies to domains where the things you're buying aren't turnkey solutions, but that is many domains.
Hmm? I suppose I was unclear. I wasn't making a comment about the relative quality of the software itself- I was pointing out that once you have decided you want to pay for support, for some domains, the for-pay support available for the open-source product is better than the for-pay support available for the closed-source product.
Really, "what level of support do I want to pay for?" is a question you have to answer separately from the "should I use open source or not" question. You can often buy closed source software without support, just like you can often buy support for open source software. The quality of the available support varies quite a lot, and really should be evaluated primarily on the reputation of the company you are buying the support from, but in my experience? proprietary software is not the clear winner in the paid support department.
I actually think that a lot of managers are sold a bill of goods with the "someone to blame" line- The software being closed-source and paid for doesn't automatically mean that the support is any good. I've been in so many situations where we end up needing to call support because something broke, we don't have the source... and a lot of times? well, I (and just about any other sysadmin) could give you really long stories of incompetence.
> There are many people that don't want to be a collaborator because they don't enjoy dealing with software.
Yes. Definitely true. Also, there are people/organizations who do enjoy dealing with software but don't have the time/resources to work on a particular piece of software that they need and use (because, for example, their core business focus is on some other area.)
For them, too, it makes economic sense to buy it, even though they are capable of doing the work themselves given enough time.
Yes they can fork and pay someone to resolve issues for them. If the maintainer isn't paid by the business using the project then he owes them absolutely nothing.
That's why I'm talking about collaboration, and that's what developers often forget. Making a pull request is simple,80% of the time, the user has the capability to patch a bug, but he can't be bothered with that yet complains. That's entitlement.
Grabbing a quote like that out of context changes it's meaning entirely.
The entire context for your quote is about purchasing proprietary software or a paid support license... So yes, the maintainer is being paid by the business using the project and owes them support.
> users are treated as both beta-testers and maintainters, and are expected to find and fix bugs themselves.
FWIW, this is probably both an historical attitude and a population difference. If you and a colleague at a university just made csh to get your jobs done, then you will help each other out by doing the development. Because ya'll are also the entire userbase, then you are also the beta-testers. Back then, if you used a computer, it was because you were either developing software or entering data for a developer. Not very many non-developer users touched computers until the 80s; most people developed some kind of software, even if it was trivial BASIC programs on a Commodore.
In the OSS world, you have always been expected to contribute fixes to bugs that affected you, because the tools and source code were in your hands. For most non-developers, there exists only a lack of skill to stop them from fixing bugs or at least filing usable bug reports.
Nowadays, there are much more users who cannot or do not submit bug reports, let alone develop software. Nevertheless, the attitude since the days of csh has not changed much, because not a generation has passed since OSS went somewhat mainstream (e.g. in the data center).
Whether OSS will leave behind the historical attitude that users should be able to understand the software they use (this seems a responsible attitude to me) remains to be seen. Regardless, the developer-base will likely continue to proportionally shrink and users will proportionally become less able to understand their computers.
You can do that with some proprietary software too -- proprietary doesn't have to mean no source code and no source code modification, unfortunately it has come to mean that for too many businesses and users willing to pay money to those businesses, so yeah, it's a point in favor of open source. I also appreciate that contributing to and encouraging use of open source has a societal benefit of training my eventual replacements for free, and open source of a particular license guarantees improvements to that software from other parties than the primary maintainer remain open.
First of all why would you purchase software that didn't have the features you wanted or was buggy without evaluating it? Even so, many vendors accept returns.
And if you think spending countless hours implementing and testing features in a codebase (that you have to spend hours just learning, and that is if you're lucky and already are familiar with the programming language its implemented in) is "better" than just paying a vendor to do it, then probably no rational argument would convince you otherwise, and I would withdraw my objection.
As far as I've been able to tell, after 20-odd years of software development and system administration, the only difference is that you have to pay for proprietary software and you can't change anything even if you know where the problem is.
Any opensource project has other opensource competitor. This makes OSS more competitive against proprietary software. If you choose to use PS1(proprietary software1) in your project and after 2 years PS1 changes their licensing and requests 3x more money of annual license you either have to switch to COMPATIBLE competitor, which means PS2 must operate on the same protocol/interface that PS1, which nearly never happens. Instead companies try to make their PS more vendor-locked. In opensource world, there are usually converters, importers, and switching from deprecated or slow OSS1 to better alternative OSS2 is easier and cheaper. At least that was my experience when we were considering various frameworks or libraries at work or in my projects. It's now one of the main reasons why I stuck with OSS at all times.
It's an overly generally statement. What I believe the author really meant is that open source, given sufficient and equal time and resources, will generally produce better software than a closed source equivalent.
Yeah, that's a campaign slogan of the original OSI movement, sponsored by O'Reilly and spearheaded by esr and Bruce Perens. Other slogans are "with enough eyeballs, all bugs are shallow" or the promise that publishing your source means you'll get more contributors.
Yeah, CatB became the "little red book" of the open source movement. It predates OSI and the term "open source" , but it was widely quoted as a motivation for it. The beginnings of open source, with the freeing of Mozilla, were all inspired by CatB.
ahem Free software existed long before Linux, "Cathedral and the Bazaar", Netscape and so on. It started with the GNU project in 1984. While techincally correct to say that "open source" started then, it implies that the whole free software movement came out of that one group. It didn't.
It may look like this if one only uses open techs but that's absolutely not true. There is a wide range of libraries, apps that are commercial and have no equivalent in the OS world. Open source software might give the illusion that everything can be free and high quality when in fact very few open source projects are professional grade.
Depending on software... Eclipse is shitter than IDEA, but Linux/BSD beat Windows and Mac on servers in every aspect. OpenJDK gets updates and security patches more frequently than OracleJDK...
Luckily, one of the contributors stepped up and is now the main maintainer. I still read through the issues that come in and he does a great job of responding and keeping cool. I don't know how he does it.