
Starters and Maintainers - fcambus
http://www.jlongster.com/Starters-and-Maintainers
======
avitzurel
Open source is really hard.

* 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.

~~~
seiji
_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.)

~~~
x0x0
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!)

~~~
pedrocr
> 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.

~~~
x0x0
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.

------
voltagex_
>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.

~~~
hyperknot
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/](http://isitmaintained.com/)

~~~
mpdehaan2
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 :)

------
alexandercrohde
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.

~~~
pedrocr
> 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".

~~~
johnmaguire2013
> 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?

~~~
techdragon
We do have gittip, flattr, etc ... this doesnt seem to have produced much
success.

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"

~~~
xrjn
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.

~~~
crdoconnor
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.

------
AndyKelley
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.

~~~
brusch
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"

Sorry - I had to vent.

~~~
draw_down
Bummer. Know what enterprises have, though?

------
Swizec
> 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.

~~~
RossBencina
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.

------
swanson
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.

~~~
jlongster
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.

------
kator
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".

------
Touche
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.

~~~
ATsch
alternatively, let them fork it and put a link to their repo in the README

------
dustingetz
> 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.

~~~
blazespin
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.

------
amasoean
Maybe that could be a solution: a platform enabling people to offer paid
support for their open source projects –
[https://news.ycombinator.com/item?id=10805236](https://news.ycombinator.com/item?id=10805236)

When things become popular, it would be much easier to find and recruit
maintainers if there was some regular monthly income attached to it.

------
darylteo
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

------
dustingetz
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.

~~~
sheepmullet
> 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.

------
blairanderson
99% of noise is from email notifications for conversations on issues.

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.

------
joepvd
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.

------
mattei
This reminds me somewhat of "Commandos, Infantry, and Police"
[http://blog.codinghorror.com/commandos-infantry-and-
police/](http://blog.codinghorror.com/commandos-infantry-and-police/)

~~~
tomaskafka
Yes - or pioneers, settlers and town planners of Simon Wardley:
[http://blog.gardeviance.org/2015/04/the-only-structure-
youll...](http://blog.gardeviance.org/2015/04/the-only-structure-youll-ever-
need.html)

It's hard to have to play all the roles.

------
booleanbetrayal
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.

------
programminggeek
I had similar feelings, so I don't open source things anymore. I wrote about
it here: [http://brianknapp.me/open-source-guilt/](http://brianknapp.me/open-
source-guilt/)

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.

~~~
pgeorgi
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".

------
bliti
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? (:

------
jondubois
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.

------
fourstar
Please just keep maintaining nunjucks :)

~~~
jlongster
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.

