* Sometimes, issues are just questions that belong on StackOverflow or any other forum online.
* Often people suggest pull requests that don't really fit what you see as the roadmap for the project, you have to be polite and respectful.
* There's the case of beginners trying to jump in, if your project is something that appeals to beginners (eg:Rails), you are in for a whole bunch of other issues supporting the getting-started.
* There's a lot of stress involved with managing all of this, if you are alone in the project it can get pretty overwhelming.
* Finding collaborators on open source projects is not easy as well, most of the times the project README doesn't suggest that collaborators are welcome and appreciated.
* Forking creates a lot of fragmentation.
* I can think of many projects that lost the steam. Resque is the perfect example for me, even with new contributors it failed to get going and Sidekiq won.
* We still need to figure out a reward system for open source to prevent maintainers from losing steam along the way.
I mean I love all the contributors - I do, but a few nights a week is fun, all of them is bad, when it starts to eat your Saturday, that's a steamroller.
There's reward, yes, but mostly there's a lot of people who (queue up the Sixth Sense voice) that WANT THINGS. I mean, everybody totally means well, they do... but so many people wanting so many things.
You could spent all your time just helping people who didn't read the docs, helping misunderstandings, restating the obvious, code review, website editing, so many things. And you have no time to do them all flawlessly, so you do them all the best you can, and get hammered on the things you couldn't be perfect on. Then you get into Catch-22 scenarios as the project grows and must please conflicting audiences.
Open source is really really really hard.
I think ones with very focused audiences (say, like, insect biology?) may have it easier - the more general purpose you are, the greater the demands from diverse audiences.
Programming languages may have it the hardest, I don't know.
Given, most people will probably think I succeeded at all of those things, but it also broke me in ways that would make me reconsider doing it that way again. Maybe everybody has energy to do it some, but ... it's rough.
There's so much more to it than just writing code too.
I think the worst is when some people show a sense of entitlement and default to throwing a tantrum when a response doesn't go the way they want, even if it is the logical outcome of what has happened.
For example, one time I had closed an issue after asking for a clearly worded explanation to a claimed bug in implementation and/or a reproduction, and I got a broken reproduction with more unclear response. After closing the issue, I got some rapid fire responses in the issue from the person with all sorts of accusations.
After the person fixed the reproduction, it turned out the person was right, but unclear explanation and a supposed reproduction that did not show a bug caused a lot of wasted time because the person was too hasty, and the tantrum only added stress for all parties.
These are the types of interactions that make me want to not do open source work - people not taking the care to do the necessary investigation to avoid wasting time and generally respecting other people. It's as if those people don't realize that open source maintainers are there precisely to help if they can.
My ideal job would be as a GitHub janitor. Cleaning up and helping with projects that have become too unwieldy or need a little duct-tape to keep going.
Sometimes, issues are just questions that belong on StackOverflow or any other forum online.
Exactly. GitHub offers no support for on boarding new issues, so a lot of well meaning misplaced questions can pile up quickly. There's no GitHub issues MOTD or "have you tried X, Y, Z first?" or even a way of saying "issue tracker is for provable bugs only — not for asking why our software doesn't compile on your 16 year old version of RedHat."
We still need to figure out a reward system for open source
The universal currency for exchanging units of time for units of economic productivity is money. (and not "oh, my employer gives me $5 a month to donate anywhere I want, we are so special!" but rather, $200k to $3m per year to projects that help run your company.)
In other news, people continue to be surprised that demand for free labor outstrips supply :D
We've discussed this here before, but I bet the majority of companies are parasites. Heavy consumers of open source, with virtually 0 contributions of money or time. I think we should resolve, particularly those of us in a position to make it happen, to donate to open source projects.
I do (and I stay anonymous for multiple reasons) run a small open source ML project. I ignore virtually all support requests, but if you are a heavy open source contributor, you will get a response. You should mention that in emails; I'll go out of my way to help you (and often even promptly!)
+Lots to wanting to help heavy contributors first.
While there are a lot of "hey free software" people who don't contribute back, I love those non-contributor companies when they pay actual money for something. My experience is those are usually very reasonable with time-table on fixes and understanding, and the business relationship adds value. Maybe this is more about the maturity level of the company you are likely to be working with, I don't know.
If someone is however just a user, though, often they feel obligated to get infinite value rather than just the value they are paying :)
> I ignore virtually all support requests, but if you are a heavy open source contributor, you will get a response. You should mention that in emails; I'll go out of my way to help you (and often even promptly!)
Seems like a very sensible policy but will people really volunteer that in emails with no notice? Or do you state that somewhere in the project documentation? I'm a reasonably active open-source contributor but it wouldn't occur to me to mention it when sending an email to a project in an unrelated space.
I actually do mention I'll make an extra effort for you if you contribute to OS. I added it after recognizing the name of someone who emailed me, realizing I'd been using software he wrote for years, and feeling like I owed him an effort.
That said, I think it never hurts when asking an OS contributor for a favor to point out you do the same, even to a completely unrelated project.
I definitely think there should be a more established system of contributing money to open source.
There's also a matter of perception that Open Source means FREE, while yes, you don't HAVE to pay for it. a lot of times you SHOULD.
I am working on a big open source project now in the DevOps space and right out of the box I am going to have a "Pro" version. Maybe more projects should adopt this approach.
I would call those companies epiphytes [0], not 'parasites', which is untrue and pejorative. Adoption of FOSS is good for society whether or not adopters contribute back to the project (even though they should).
Well, they provide software engineers with a living so these same software engineers can build open source software in their free time, so that software engineers can use the open software at work. Just like doctors who, without fees and in their own time, devise new ways to perform life-saving surgery and trying it out on willing patients.
If you put a CONTRIBUTING or CONTRIBUTING.md file in the root of your repo, a link to it will appear on the top of the page when people create issues or pull requests.
Yeah, so this is an interesting feature because in my experience it doesn't work.
[We added one](https://github.com/kennethreitz/requests/blob/master/CONTRIB...) for the Requests module a little while ago because we kept getting bug reports that contained incomplete tracebacks or vague problem statements, or questions that were better suited to Stack Overflow.
However, we still get plenty of issues opened that suggest that the user hasn't read the CONTRIBUTING.md. We still get questions on the tracker, we still get people not telling us what version they're using or what platform they're running on.
What I want to know is: is this our fault? Is our text bad? Or does GitHub's UI not accentuate the need to read this document firmly enough?
People don't read. That's pretty much it. Maybe, maybe, if there was some in-line text above the issue form submission, and it was very short (like one or two sentences), people would read that. But any long-form prose is going to be skipped, and likely something that requires clicking a link to read an external CONTRIBUTING document isn't going to be read either.
I ran into this a lot in pre-GitHub (and pre-git) days when maintaining OSS. It got to the point where I would reply to emails with a simple one liner "Addressed here: [link]" or, "Bug report requirements: [link]". I felt horribly rude doing so sometimes, but I realized that people were not respecting my time by failing to take a minute or two to read through the bug report guidelines, and so I wasn't going to waste my time being polite. There's unfortunately a lot of entitlement among open source users, and it gets tiring after a while.
Yeah contributing.md doesn't get read much, or it gets skimmed over.
Issue templates seem to MOSTLY fix the problem, so we wrote a bot that sticks in some canned questions when it looks like your bug didn't follow the template. People recoiled to the bot for months but new users were totally fine with it.
I really wish GitHub had some sort of optional facility for a stock template for the "bug" field, as it would save collective years of people's combined lives. It would just need to populate some text in the issue box by default. Call this ISSUE_TEMPLATE.md if you want, etc.
Various third party attempts to do this - like use this bug page instead of github's new issue form, don't really work as the one NICE thing about github is that everyone knows how every project sort of works. Sort of. Which is also the one nice thing as they don't join the lists or really understand how various projects really really work :)
> The universal currency for exchanging units of time for units of economic productivity is money. (and not "oh, my employer gives me $5 a month to donate anywhere I want, we are so special!" but rather, $200k to $3m per year to projects that help run your company.)
>Well, so much for catching up on these issues tonight. Maybe I’ll just add DEPRECATED to the README, that’ll fix it.
Please, please, if you have too many projects like the author or myself, put a huge note in the README that it's not maintained. If you're lucky, there'll be an active fork you can point people to.
I wish GitHub had a proper UI for deprecating/abandoning projects and setting another fork as the canonical source.
> I wish GitHub had a proper UI for deprecating/abandoning projects and setting another fork as the canonical source.
Something along these lines would be really awesome!
I dream of a Github UI that helps me see/search/discover other active forks of repos, as well as relevant branches/patches on other forks (whether attached to PRs or not).
When I discover projects of interest on Github without obvious active maintainers, there are often (somewhat hard to discover/find) other folks that have picked it up and made a few patches to solve issues they encountered, and these are sometimes quite relevant to my own needs.
> I wish GitHub had a proper UI for deprecating/abandoning projects
As we see from OP, it's really hard to admit that you don't have time for your own project. Ideally, inactive maintainers will let go and give push right to whoever is working on their project. But more often, maintainers simply stop being active. This discourages contributors from even submitting bugfixes because the users won't profit from their work. (I've once seen a project with 3 forks, each containing a slightly different commit fixing the same bug.)
It would help much already if GitHub displayed a prominent notice "the activity on the project you're looking at is very low, but fork A and fork B both have higher recent activity".
Something like a compact summary of the network graph. (The network graph is great, but has too much whitespace and requires too much scrolling to get an overview. Especially if there are 30 forks of people just committing one local hack or config file.)
I wish GitHub had a proper UI for
deprecating/abandoning projects and
setting another fork as the canonical source.
More project authors should create organizations that can live on as the canonical source of their projects. That way, there never has to be a 'slightly more canonical' fork, but instead just a new maintainer.
This is my new habit.
I always open an organization first.
First, it's easier for people to contribute when something is associated with an organization, they feel the credit is more evenly distributed, it's also easier to just leave since someone can jump in with no URL changes. Easier on the users, easier on the contributors. Win
> I wish GitHub had a proper UI for deprecating/abandoning projects
Would this be equivalent to implementing the dislike button for Facebook, which we know will be never implement?
I'm currently indexing most of the popular repositories on GitHub (500+ stars) so they can be searched by commits, diffs, etc. and what I've noticed is:
- GitHub hosts a lot and I mean lots of repositories.
- People fork popular repositories like crazy but the vast majority do nothing with their forks.
Would making it easier to deprecate or make it more noticeable that a repo has been abandoned be good for GitHub? Don't get me wrong, GitHub is the current leader for hosting Git repositories and the number of active repositories is still quite significant, but if you dig deeper, you'll find a considerable amount of unused/never touched repos.
From GitHub's point of view, I really don't see any benefits for implementing such a UI, much like it makes no sense for Facebook to implement a dislike button.
While not a GitHub UI feature, isitmaintained.com [1] comes close to providing a quick overview about a project's status. When choosing open source libraries, I always go there first:
[1] http://isitmaintained.com/
That is pretty neat and I love seeing more project statistics- however, fair warning, I was a bit surprised it doesn't scan issues older than 6 months.
As a result, if a project closes all issues in either a day or ten years, it will report that the mean time to resolution is 1 day and not essentially ten years :)
Better still people wishing to make a name for themselves could just peruse the deprecated/abandoned repositories, fix them up, and maintain them. Viola, you now have a great resume item and likely learned a large number of useful skills and production-environment experience.
I empathize with the author. The root of the problem can be interpreted as the fact that a well maintained production-ready library is almost an engulfing charity service for the author. Ironically, economically, the optimal solution is for the masses benefitting from the library to return some of that benefit (perhaps in monetary form) to the author. But culturally this is not what free-software is about...
That's the irony and inefficiency of open-source software.
> the optimal solution is for the masses benefitting from the library to return some of that benefit (perhaps in monetary form) to the author. But culturally this is not what free-software is about...
There's been quite a bit of improvement in that problem space. Crowd-sourcing is now considered by users a natural way to fund new work. So much so that in more user facing apps users are constantly asking about it if you don't have a campaign already. There are also micro-transaction solutions like gratipay (previously gittip) that are more open-ended and continuous which probably works better for lower layer projects and when developers don't want to fiddle with managing crowd-sourcing campaigns. Github could very easily own that space if they implemented something like "give x$ per month to every project I've starred".
I think it's because it's not seamlessly integrated into Github and instead relies on external services that aren't intercompatible. If Github integrated/bought one of these services and made everything work smoothly with their billing system, I think many people would love to contribute. Maybe even make "corporate" contributions, although I don't know how that would work.
I'd much rather have a 'corporate' version where you could sell commercial licenses through github for $250-$350 to bigcorps and VC funded startups than a gittip where you can beg for 5 cent donations from developers.
Developers of open source software may be compensated by employment, contract, donations, sponsorship, and even social standing. Moreover, they benefit from having free access to the tools of a highly lucrative field. Everybody's got to get paid, and free software's “culture" hardly stands in the way.
Balance that though against the fact that OSS has been massively, mind-bogglingly successful, and all we're doing here is nitpicking various annoyances from the privileged vantage it has given us.
I don't see how money helps with the problem of not having time for a second job. You could try to use the money to pay someone else but that still means trying to find trusted maintainers.
Not necessarily. The solution could well be to actually hand over the maintainer job. Grant someone commit rights, clearly say so as such, and off you go :)
I make 2 compromises in my open source software work in order to keep up with all the projects I start and at least do a decent job maintaining some of it:
1. I don't support old stuff. No old operating systems, no old dependencies, no old compilers, etc. The answer to all support requests of the sort is "sorry, I don't have the time or funding to support versions below XYZ."
2. I'm not afraid to roll the major version number of my software. If I make a design mistake, I fix it without regard for backward compatibility, and then I don't support older versions.
These two things really make a big difference in lowering the difficulty of support without compromising the quality of at least the latest version of code. And if the users are using the latest version of everything and need support, great! They probably have such a similar environment to my own that I'll have no problem reproducing their issues.
are you the three.js "maintainer" ?
My code breaks every time I update three.js I would be fine with that if the release notes would point that out directly. It's really a nice library but it would be great if he handled the project a little bit more "enterprisey"
Your frustration is justified. I think it's the responsibility of the maintainer who bumps the major version to include a checklist of things to do to upgrade to the new major version.
> 9 new issues since I last checked. 2 new pull requests. Hopefully most of the issues can be closed, and the pull requests are trivial. Ugh, nope, these are some significant changes. I’m going to have to think about this and engage (politely) in a long discussion. They also didn’t update the docs, and this is a breaking change, so we’ll have to figure out how to tell everyone to upgrade.
>/.../ who am I kidding, that would just stress me out more. It’s not like I always have time to respond. At least now I can pretend like this doesn’t exist when other things are stressing me out."
So much this. This is why most of my opensource projects come in the form of "Here's the code, if you don't like it, fork it and maintain your own damn fork". In 5 years of putting code on GitHub I've probably merged less than 10 pull requests on projects that don't directly put food on the table.
It's unrealistic for people to throw drive-by PRs and expect them to be merged. I can't imagine many cases where a drive-by PR should be merged, maybe:
* Legitimate bug fix with clear explanation.
* Non-breaking enhancement that maintainer agrees with (low likelihood of agreement)
Any other use of PRs (e.g. breaking change), if acceptable at all, should be coordinated with the dev team before expecting it to be merged. As the article says "engage (politely) in a long discussion." I'm not convinced that a PR should be the starting point for that long discussion, but that's how the github workflow works. imho the bar should be set very high for this kind of PR.
Another use of PRs is: here's an interim patch that I made, that I don't necessarily expect you to merge, but maybe someone else will find it useful for developing a mergable patch. I see that quite a bit, and I think it's useful.
The Github workflow doesn't really model intents of the above scenarios, or varying policies of different projects. I think it contributes to the problem.
Another interesting wrinkle is that starters often get the credit or notoriety for the project, even if there is a large group of others now maintaining and supporting the project. Not to say that the project starters have abandoned the project or did anything nefarious, but when you think of projects like Rails or Backbone -- you think of DHH or Jeremy Ashkenas, not necessarily the other core committers now involved.
That's part of the guilt, too. We over-emphasize starters, when maintainers (who very well could be the same person!) should really get most of the credit. Well, at least equal. Unfortunately social dynamics tend to glorify single people.
I've long observed this, but in an company context rather than open source. The glory goes to people who start things, even when what they start is a buggy mess. The people who fix the problems and put out the fires are appreciated, but well, that's what they're supposed to do!
Lol I just read this after a "break" working on my winter break on a project I "started" almost three years ago. I checked in with the community and it turns out they're still using the junk I made years ago, it's helping people be really productive, but nobody understands how to modernize it.
So here I sit three years after "starting" the project and basically going back to work. Now I've spent the last 8 days straight coding about 6 to 10 hours a day on my vacation to "start" it again, but way cleaner. My two goals are, one I want my wife to be able to use it (ease of use) and second I want to empower the guy who picked it up to be great at maintaining it after I eventually return to the real world.
I learned years ago that I am good at the blank page, the staring back at you empty cursor is my favorite time. The clay is fresh and the images dance in my head of all the potential of that flashing cursor. I'm not the guy who really enjoys wading in up to my ears into a million lines of code and refactoring it to some new vision. I can do that but it doesn't get me out of bed every day at 5am on my "vacation".
If you're going to abandon a project why not just add collaborators? Add anyone that submits a PR. Let them take over the future vision of the project if you're no longer interested in it. I think that's good policy anyways, anyone who takes the time to submit a PR (and I deal with so many people who submit a million issues but never will make even the slightest change) has an investment in the project that you may no longer have. Let them own it.
> I’m going to be clear that code I put on github is experimental and I’m not going to respond to issues or pull requests
Stating the project maturity is nice but not that important - it's pretty easy to glance through a repo's code, commits, issues and PRs and judge the project's maturity and how many people are using it and how likely ongoing investment is to occur over the next couple years. You can also look at the maintainer's online presence, blog, talks, social media (be it a person, a team, a corporation, startup or nonprofit). Pretty easy to predict what their priorities are and will be.
People get bit by project maturity only once, and i figure by this time next year it will be common knowledge that for your random semi-popular github project on social media, maintenance is never implied unless promised, and even then not really unless everyone's incentives align.
Yeah, it's all about what have you done for me lately on github. Even extremely well maintained libraries suffer from bitrot if they're not touched recently.
I've started projects that were contextual to the stuff I was working on at the time, but once I stopped working on it, there really wasn't much point in maintaining the projects anymore. I feel quite bad about it, but I can't remove it either since I show it to potential recruiters as well.
Even funnier was one of my projects gained interest in the Android community, and I don't even do any Android stuff, which made it almost impossible to support them.
Definitely a tip of the hat goes out to those who stay the course and maintains the projects they start. It's a gruelling journey
The thing is, people want their new project to get popular, because it validates them and is great portfolio and is motivating to work on, but you can't just stop once you have users. a lot of maintainers just quit when they got the users and used them for what they wanted. That's not very cool. So I don't think the project maturity is so important but rather that the project maturity not go backwards. If you're promoting your stuff on social media, positioning your work to be used by beginners, it needs to be maintained at that level until the users move on. I'm not aiming at anyone in particular right now, im just saying as a thought experiment, what if you make some great thing library and everybody loves it then a year later some idea gets back ported from Elm or ClojureScript and now someone else's stuff is exploding. Are you gonna move to the shiny thing and burn the people who believed in you? It's an impossible choice. I think a lot of people are gonna get burned on this in the next two years and JavaScript world will move back towards frameworks rather than libraries.
> I think a lot of people are gonna get burned on this in the next two years and JavaScript world will move back towards frameworks rather than libraries.
I don't think so.
Most of the companies I have worked at have the resources and expertise to maintain a couple of open-source libraries if the authors move along to greener pastures.
On the other hand only very large companies have the ability to maintain abandoned frameworks.
It is also a lot simpler to change libraries than it is to change frameworks.
There was this interesting thread a while ago of someone deciding to give commit rights to anyone who made a pull request. As I remember it, it works out well for the author: Less maintainer time, and the quality of the PRs improved immediately. Unfortunately, I have not been able to dig up the thread.
This resonated with me so deeply. I have played this conversation over and over in my head, wondering "why?" ... but somebody has to. It's often a labor of necessity, not love.
Back in the day, open source projects were just a tarball on some ftp server. Maybe, just maybe, the README contained an email address to send patches to.
That probably wasn't such a bad model after all.
If you worry about endless support via email, create per-project aliases that at some point may autoreply "this project is not supported any longer. Feel free to set up your own fork".
Aside from the different "tipping" services, is there a way open source authors and maintainers can raise funds without doing crowdfunding? Something that let's them sell something to raise funds like when schools sell chocolates? (:
If you don't have a vision for your open source project, then I agree that you probably shouldn't be maintaining it - In this case, it's better to hand it over to a different maintainer who does have a vision.
Nunjucks was one library that I finally transitioned to another maintainer, carljm. I don't maintain it at all! I did for about 3 years though, so it was definitely time for someone else to step in, and he's doing a great job.
* Sometimes, issues are just questions that belong on StackOverflow or any other forum online.
* Often people suggest pull requests that don't really fit what you see as the roadmap for the project, you have to be polite and respectful.
* There's the case of beginners trying to jump in, if your project is something that appeals to beginners (eg:Rails), you are in for a whole bunch of other issues supporting the getting-started.
* There's a lot of stress involved with managing all of this, if you are alone in the project it can get pretty overwhelming.
* Finding collaborators on open source projects is not easy as well, most of the times the project README doesn't suggest that collaborators are welcome and appreciated.
* Forking creates a lot of fragmentation.
* I can think of many projects that lost the steam. Resque is the perfect example for me, even with new contributors it failed to get going and Sidekiq won.
* We still need to figure out a reward system for open source to prevent maintainers from losing steam along the way.