Starters and Maintainers
jlongster.com
jlongster.com
* 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.
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.)
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!)
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 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.
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.
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.
This!
I would love to see this happening.
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.
[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?
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.
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 :)
I totally got the second job feeling.
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.
Many of the responses I get are like https://github.com/bruderstein/nppPluginManager/issues/1
The most negative one I got was being told that "time doesn't fix issues, work does" - which is pretty fair.
The most helpful response is something like https://github.com/asb/raspi-config/issues/57. Yes, I could be more tactful but it was never my strong point.
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.
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.
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
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.
Doesn't show PRs but all PRs come from commits on some fork/branch and those you can see.
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.
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.)
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 :)
That's the irony and inefficiency of open-source software.
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 would love this. Has this been discussed anywhere?
Patreon does seem to be developing a bit of a traction here too now. "I work on xyz, keep me funded so i can continue working on xqyz"
> could very easily own that space if they implemented
> something like "give x$ per month to every project
> I've starred"
Then, as mention downthread, there are Flattr, Gittip/Gratipay and Patreon.
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.
Sorry - I had to vent.
What, charge you for a LTS version? :)
>/.../ 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.
* 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.
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".
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.
When things become popular, it would be much easier to find and recruit maintainers if there was some regular monthly income attached to it.
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
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.
Turning off Github Issues is the easiest way to change the expectations.
On another note, GitHub Issues should be Opt-In instead of Opt-Out for Repo owners.
It's hard to have to play all the roles.
For me, open source projects aren't worth my free time. I'm fine with giving code away. I'm less fine maintaining it years later.
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".