My condolences, you’re now the maintainer of a popular open source project
runcommand.io
runcommand.io
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 think more people need to do better at communicating better is what it comes down to.
[1] https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/perm...
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 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.
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.
Edit: misread post, disregard
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.
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).
The good people contribute features, bug reports, bug fixes, documentation, etc. The project wouldn't be as good as it is without them.
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 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!
That's not always true. They may not have the necessary skills. That's no excuse for laziness in reporting problems though.
Learn the necessary skill.
Dismissing users because they do not have the skills to fix every problem is absurd.
feature requests
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.
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.
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.
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.
I am assuming it refers to https://help.github.com/articles/blocking-a-user-from-your-o...
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.
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.
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.
- take breaks. go AWOL for 2 weeks. it clears the mind
- ask the user to provide a test case to reproduce. if they cannot, close the issue after a month or so
- mark issues as "needs test case" or "has test case"
- use email instead of GitHub notifications. mark as read, labels, folders, etc. are all invaluable
- if some user is abusive, cut them out immediately (e.g. ban them from the GitHub org)
- do a little bit every day so you don't become overwhelmed
- set up automated tests that run for every PR. projects without tests are impossible to maintain.
Good luck!
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.
If there are too many issues it means that your guidelines for contributing is not clear enough.
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!
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?
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.
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.
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.
Github should think about how to build this IMO, it would make things much better if there were levels of involvement:
-1) Asked for help before and NOT valid
-1) Pull request not valid
-1) Noisey user (might have positive Karma but often creates irrelevant issues).
0) Not asked before
1) Asked before and valid
2) Asked before and committed fix
3) Pull request valid
4) Pull request merge
5) Complex feature merged
6) Contributor
7) Maintainer
Now each of these can be discussed how to get there but if you could by default only see one level above and 3 levels below that would help a lot.
The default count of issues and view of maintainers/contributors on github should not include anything below level 1.
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.
If it's in the docs/easily googleable could be another minus.
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.
[3] https://github.com/umbrellajs/umbrella/issues?q=is%3Aissue+l...
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.
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.
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.
Of course, the users will blame you.
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.
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.
There is also Patreon. I have seen people fund project maintainers this way. Enough for a full income https://www.patreon.com/foosel
> 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.”
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.”
> 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.
> 2. There are now a critical mass of reliable open source
> components, which accelerates your product’s time to market.
> 3. Open source produces quantitatively better software.
> 4. Near and dear to me personally, open source permits
> companies to collaborate on common problems without
> complicated business agreements.
> "Open source" now means two things.
>
> Clearly, there’s the official definition, a permissive
> license which grants certain 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.
> 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.
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.
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.
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.
I would guess that a large portion of these projects are just personal projects that have little value to anyone other than their author.
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.
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 mainly uses open source software for most of my work, I'm not so sure about this.
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.
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.)
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.
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.
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.
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.
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.
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.
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.
http://jordi.inversethought.com/blog/5-things-we-have-forgot...
I'm pretty sure it's called Linus law and it was described in "The Cathedral and the Bazaar" [1]
http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral...
Open source started in 1998 during the release of Mozilla.
Literally, the only difference is the license.