8 ms·

Starters and Maintainers

304 points by fcambus 11y ago

Swizec 11y ago
> 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 11y ago
  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.
avitzurel 11y ago
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 11y ago
  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 11y ago
    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!)
    - mpdehaan2 11y ago
      +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 :)
    - avitzurel 11y ago
AndyKelley 11y ago
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 11y ago
  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 11y ago
    Bummer. Know what enterprises have, though?
  - AndyKelley 11y ago
    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.
  - deleted 11y ago
    [deleted]
  - corobo 11y ago
    > it would be great if he handled the project a little bit more "enterprisey" What, charge you for a LTS version? :)
darylteo 11y ago
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 11y ago
> 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 11y ago
  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.
- voltagex_ 11y ago
  I want to maintain every good idea I have - but there are only 24 hours in the day. I definitely empathise with the author here.
swanson 11y ago
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 11y ago
  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.
- draw_down 11y ago
  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!
- VeejayRampay 11y ago
  Thanks to Jeremy, Aaron, Rafael and all the other hard working Rails people doing great work for next to no recognition. I appreciate it immensely.
voltagex_ 11y ago
>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.
- jonesb6 11y ago
  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.
  - voltagex_ 11y ago
    I tried a couple of times this year. It can quickly overtake your own projects in terms of time taken.
- aaronbrethorst 11y ago
  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.
  - avitzurel 11y ago
    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
- dantillberg 11y ago
alexandercrohde 11y ago
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.
- _greim_ 11y ago
  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.
- deleted 11y ago
  [deleted]
- pedrocr 11y ago
  > 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".
  - egor83 11y ago
    > could very easily own that space if they implemented > something like "give x$ per month to every project > I've starred" That's exactly what BountySource is about. Then, as mention downthread, there are Flattr, Gittip/Gratipay and Patreon.
fourstar 11y ago
Please just keep maintaining nunjucks :)
- jlongster 11y ago
  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.
amasoean 11y ago
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.
blairanderson 11y ago
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.
bliti 11y ago
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? (:
deleted 11y ago
[deleted]
deleted 11y ago
[deleted]
dustingetz 11y ago
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 11y ago
  > 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.
mattei 11y ago
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 11y ago
  Yes - or pioneers, settlers and town planners of Simon Wardley: http://blog.gardeviance.org/2015/04/the-only-structure-youll-ever-need.html http://blog.gardeviance.org/2015/04/the-only-structure-youll... It's hard to have to play all the roles.
booleanbetrayal 11y ago
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 11y ago
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 11y ago
  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".
joepvd 11y ago
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.
kator 11y ago
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 11y ago
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 11y ago
  alternatively, let them fork it and put a link to their repo in the README
jondubois 11y ago
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.

304 points by fcambus 11y ago

> 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 11y ago
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.

avitzurel 11y ago

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 11y ago
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 11y ago
  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!)
  - mpdehaan2 11y ago
    +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 :)
  - avitzurel 11y ago

AndyKelley 11y ago

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 11y ago
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 11y ago
  Bummer. Know what enterprises have, though?
- AndyKelley 11y ago
  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.
- deleted 11y ago
  [deleted]
- corobo 11y ago
  > it would be great if he handled the project a little bit more "enterprisey" What, charge you for a LTS version? :)

darylteo 11y ago

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 11y ago

> 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 11y ago
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.
voltagex_ 11y ago
I want to maintain every good idea I have - but there are only 24 hours in the day. I definitely empathise with the author here.

swanson 11y ago

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 11y ago
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.
draw_down 11y ago
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!
VeejayRampay 11y ago
Thanks to Jeremy, Aaron, Rafael and all the other hard working Rails people doing great work for next to no recognition. I appreciate it immensely.

voltagex_ 11y ago

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

jonesb6 11y ago
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.
- voltagex_ 11y ago
  I tried a couple of times this year. It can quickly overtake your own projects in terms of time taken.
aaronbrethorst 11y ago
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.
- avitzurel 11y ago
  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
dantillberg 11y ago

alexandercrohde 11y ago

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.

_greim_ 11y ago
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.
deleted 11y ago
[deleted]
pedrocr 11y ago
> 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".
- egor83 11y ago
  > could very easily own that space if they implemented > something like "give x$ per month to every project > I've starred" That's exactly what BountySource is about. Then, as mention downthread, there are Flattr, Gittip/Gratipay and Patreon.

fourstar 11y ago

Please just keep maintaining nunjucks :)

jlongster 11y ago
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.

amasoean 11y ago

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.

blairanderson 11y ago

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.

bliti 11y ago

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

deleted 11y ago

[deleted]

deleted 11y ago

[deleted]

dustingetz 11y ago

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 11y ago
> 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.

mattei 11y ago

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 11y ago
Yes - or pioneers, settlers and town planners of Simon Wardley: http://blog.gardeviance.org/2015/04/the-only-structure-youll-ever-need.html http://blog.gardeviance.org/2015/04/the-only-structure-youll... It's hard to have to play all the roles.

booleanbetrayal 11y ago

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 11y ago

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 11y ago
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".

joepvd 11y ago

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.

kator 11y ago

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 11y ago

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 11y ago
alternatively, let them fork it and put a link to their repo in the README

jondubois 11y ago

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.