Yes! Rod Vagg (technical chair of Node.js) is one of the pioneers of this way of developing software. He was recently on the podcast "Request For Commits" discussing this very topic!
Same thing happened to me: I wrote the module that does Microsoft Office files in Python. At the time, the solutions for doing it in Python were 'talk to some Java library' or 'talk to some .net library'. I read the openxml spec and made something which did basic creation, extracting text, modifying docs.
I totally didn't have time to maintain it, then Scanny took over. It's now hugely popular, the code handles non-Word OpenXML docs, and most of the code has been added or refactored under Scanny.
> I don’t recall the author now, but the gist of the argument made was that we’re too protective of our code - if you give someone responsibility, show that you trust them, more often than not, your intuition about people abusing their freedom is way off.
Maybe it was some of Pieter Hintjens writing and/or the C4 process:
Was going to suggest the same thing :) I haven't had the sort of success that the OP did, but that PR Hack post def inspired my way of operating! Yay Felix
Felix and I met some time before he wrote that blog post, and I explained our C4 process to him. His pull request hack, which I merged into C4 not long after, is neat though github doesn't provide the tools to do it easily.
I did something similar with a project I lost interest in several years ago (https://github.com/dbfit/dbfit - table-oriented database unit testing). Just gave over commit rights, and there's a whole bunch of people writing code for it and maintaining it now, still going strong. I occasionally look at the github repo, and always end up amazed how much it's moved on.
We use DbFit every day at our shop. It's really changed how we work (as DB developers). Was funny that I thought of this project right after reading this article, and how I should probably try and contribute, then I see this in the comments. :)
nice :) I built DbFit at a time when I was getting a lot of work helping companies with a huge investment in oracle pl-sql, but my interests moved on, and for a while it just felt I was holding the project back.
People wanted to implement new things, support new databases, I felt overprotective of the design, but didn't have enough time to bring new contributors onboard. So I just kind of gave up, and that allowed me to think about it from a completely different perspective. If I just deleted it, then I wouldn't care too much about it any more. Giving away the keys was kind of the same, but without preventing others from contributing. And it worked out great.
Yep, something similar happened to me - I released what is now https://github.com/punker76/gong-wpf-dragdrop on google code in 2009 (I think) then pretty much lost interest. Forward on a few years and @punker76 had uploaded it to github, and continued working on it. It was a strange feeling when I first became aware of the fork - like seeing an inanimate object come to life.
Ha, Same thing happened to me with the SAME contributor!! Benjamin Bach is an awesome dude. He helped me maintain django-dbbackup for quite some time then we found a third contributor, Anthony Monthe, who is also very interested in the project and I would say owns it now. It's been maintained by those two for quite some time now. I wish there was a way for me to buy them both a bunch of rounds of beer. :D
Benjamin Bach seems to be awesome, however there are few people like him. Chances are your contributor won't be a Benjamin Bach. If the majority were like him, I'm sure we would have much less abandoned open source projects, but the majority isn't like him. Expect the worst and slight possibility of turning out like what the author described.
Haha, I'm so glad you shared that, that makes the story even better! I don't know Benjamin beyond our short interaction dealing with moving the repo around, but yeah he seems like an awesome dude.
He's a personal friend, i can buy him a beer on your behalf ;). I think he makes it work because he works part time and uses the rest of his time on open source projects. He could easily be earning far more if he worked full time, but this is what he prioritises.
The Jazzband is a Python-focused group based around similar ideas: People can transfer their projects to the group, and anyone in the group can commit stuff and make releases.
I did this for a (not very popular) Eclipse IDE autocomplete set for a certain Lua-based game engine.
I updated to 0.9.2d and forgot about it (stopped using the engine), and someone came in with a PR for 0.10.0. I made a couple of notes on the PR, and gave the guy commit access.
He cleaned it up, and has been rebuilding occasionally when new minor versions of the API definitions come in.
The vast majority of people are pretty nice. They aren't assholes. They're just people who have the same issues you had to build the project in the first place, and want to help.
I had submitted several PRs to a Zip streaming library. The author gave me direct commit access after this. I've helped maintain it ever since. I think it can really work out in some cases.
Great story. My similar experience was in the mid 1990s. I had written a tool call PicWeb Viewer that would recursively walk directories and subdirectories containing photos, create thumbnail images, and generate simple HTML to navigate everything. My code was so simple but worked fine. I released the source code and over the next few years several people contributed modifications that made my simple bit of code awesome.
I have an EMF+ library I started the barebones of in LibreOffice. [1]
Largely due to my depression and desperate need to get a job, I never got much past an initial read of the EMF+ files, but I'd love to see someone take my branch on git, split it into its own library and then work with someone to integrate it into the Drawing Layer. [2]
Oh, and to be honest it shouldn't be that hard to work on.
It basically works via a Command pattern. That's because an EMF is a binary file that consists of a bunch of sequential records. The way it works is that you get an EMF+ file, and you read it from start to finish. Each record you read has a consistent header, and each different type of record does something - or stores an object (such as a pen or font).
My big idea is to use a base EmfAction class that has a function Read() that you use to read each type of record. You use EmfAction::ReadEmfAction() to read the next record from an ifstream, and it moves the file pointer to the start of the next record, and you just loop through the file like this:
The only snag was how to set state on the DeviceContext - I want the commands to read and store the state, and the DeviceContext should be passed into the command object and be manipulated by it via an Execute(DeviceContext&). But at the time I concentrated on how to read the objects.
Of course, EMF+ has a way of saving a DC's state, allows the DC be modified by subsequent records, and then the DC can be restored, so a stack of DCs needs to be established, but how to do this I'm not rightly sure yet.
I'm pretty certain though that I'm going to need to change the EmfRecord derived command records to start using a constructor where the DeviceContext object is passed in as a pointer.
I did the same thing..... and then the contributor took contributions from others that added security holes, removed cross platform support, and had what I consider to be low code quality. I've now disowned that project.
Therefore, I'm extremely hesitant to hand out "commit bit"s again. To make up for it I try and review PRs the day of submission; even then I don't get a lot of contributions.
There seems to be a inherent trade off between security+quality and how welcoming you are to new contributors.
On the other hand, I have taken over maintainership for some projects; but it was after months of steady contributions.
It was a project that I didn't give a lot of love, and hence just gave them commit rights. It was about a year later before I looked again, by which time they had done far too much work on top of their non-cross-platform bits for me to revert.
I still didn't use the project myself; and didn't care enough to fix it, so I just removed myself.
I'm not the parent, but I've been burned in the same way. In an ideal world, yes - that would be the right way to handle the situation. In a company you'd want to do that, and probably give the programmer a mentor who can do code reviews and whatnot.
Unfortunately thats:
- Thats a complicated conversation to have at the best of times. With volunteers over the internet its much harder to organise 1-on-1s.
- A huge time sink. Usually I could make the changes themselves in less time than it would take me to explain the changes to a junior developer. Its especially hard to justify for projects I have in maintenance mode, where I don't want to spend time working on project features at all. Long term hopefully the time investment will pay off, but they'll probably disappear long before then.
- Honestly, its also not that much fun. I contribute to opensource projects because I like making things. Managing people doesn't rub that itch.
I'm not saying I have a better solution. But faced with a stream of mediocre PRs from an enthusiastic new contributor that you don't have time to review, what do you do? Abandoning the project to the new contributor sounds pretty reasonable to me.
It's always a delicate balance, as there are obviously a fair number of people who don't know what they're doing (yet, if they're learning), as well as some malicious people.
There are ways to deal with that, e.g. force small patches that solve well-identified problems; use CI to test; involve projects' users in testing; and above all, to have other maintainers in the project who can catch such behavior and help you fix it. By yourself, you're rather vulnerable.
Ideally you have a core of 2-4 people you trust from previous projects, and then you can bring unknown people in little by little.
There is no tradeoff as such, but you do need to be more sophisticated than "here are full commit rights."
Amazing story! I maintain a network library on iOS where we have automated this process: a merged pull request earns the author an automatic invitation to join the project. The code is at https://github.com/Moya/Aeryn if anyone is interested.
It was unmaintained on SourceForge for years. Some guys put the code on GitHub and started fixing its problems. I became involved after them (to help on the OSX side initially), then contacted the original author. He was happy to see some people continuing it's development, so he gave us admin on the SourceForge project. That let us cleanly redirect people to the new GitHub project, and it's been growing decently from there (~4,600 stars on GitHub, 3.5Mill+ downloads, etc).
I was introduced to open source software in 1996 and have been a huge advocate since. About five years ago, I decided to quit my job and, shortly thereafter, went out in search of a project I could contribute to in my spare time (which was now much more abundant).
I quickly discovered that a particular piece of software I used daily wasn't really being maintained all that well, despite the fact that there were several contributors listed on its home page. A few dozen bugs reports (some even including patches!) had come in, yet only a few had even been acknowledged.
This seemed like exactly the type of project I was looking for -- something that I used every day and could help improve. I sent an e-mail to the developers stating that I was going to be devoting some time to the project, sending patches in for the bugs, etc., and asking if there was "anything I should know" before jumping in. I spent a lot of time reviewing the previous discussions on the mailing lists, examining their previous commits to see how they did things, and so on.
One of the developers finally replied -- about a week later -- and asked for my SSH key. I sent it to him and he quickly gave me commit access, thanked me for the assistance, yadda yadda.
I closed out umpteen bugs, responded to previously unanswered messages on the mailing lists, and sent patches to the developers list asking for feedback before I committed anything. Having received no responses, eventually I committed all the changes and pushed them into the master branch. Questions that I had to the other developers went unanswered, just like all the previous bug reports and user-submitted patches had.
After a while, I just quit spending any time on it. Perhaps a month after my latest fix, I look at my e-mail one day to see a flood of notification e-mails about commits. The lead developer had reverted every single commit I had made. I was looking for -- expecting -- some explanation but never received one, even after I finally directly asked, "WTF did I do wrong!?".
Nothing. No response, to this day. I eventually said "fuck it", deleted my private key, unsubscribed from the lists, and moved on. I just looked and there are still bugs open today that were open back then.
The sad part is that this piece of software is fairly widespread and a part of all of the major Linux distributions, installed by default on many of them. I think there's been one, maybe two, "releases" in the last five years.
Wow, talk about some passive-aggressive behavior on the devs' part! I think there are hazards on projects where nothing seems to be happening, like you described, and others that are fairly active. At least with the active projects, you can usually get a feel for how you might be received by reading the mailing lists. I hope it didn't put you off looking for another project to help.
You really should tell us what the software is so we can know to avoid it or perhaps find your changes, fork the project and reapply them then push to have distorts switch to this new version.
Worked well for a number of projects where developers are jerks and don't allow other talented and dedicated contributors to participate.
Want to know it too. Maybe someone of us know the Dev, and could ask why?
Or even simply have the Option, someone to fork and maintain it well.
/Sorry for Bad engl., written at Phone. Be patience :-)
What a small world, I worked with Greg at CashStar where he started the fork of django-money. I still remember the conversation we had in a meeting if we should fork the project or push our PR upstream to fix the issues we found. I'm glad our upstream PR started a trend to keep the library going. This is why I like open source, when you no longer need something you can hand it off to someone else who can take over, and let the code live on.
I offered to take over a library that provides a Pythonic interface for Redis a little while ago. The original author accepted, and I've really enjoyed bringing the project back to life.
I'll probably do something like that again - it would be great if there were a good list of projects that are looking for maintainers.
Similar story - I wrote KDocker (https://git.girish.in/projects/kdocker). It was stuck to Qt3 and I had no motivation to move it to Qt4 since it was a lot of work. Out of blue, John comes along and does a full Qt4 port. I decided to take a chance and transferred ownership of the project to him. I trusted him only because he had already written a lot of code to improve the project. It turned out to be a great decision (or luck). I just checked how it's doing today and he is still keeping it alive after all these years! (https://github.com/user-none/KDocker). Thanks John!
105 comments
[ 3.8 ms ] story [ 149 ms ] threadseeing something stay alive live this and grow due to people liking it
It's especially essential when managing a high volume of open source projects on GitHub.
Liberal Contribution and Governance Models https://changelog.com/rfc-7/
I totally didn't have time to maintain it, then Scanny took over. It's now hugely popular, the code handles non-Word OpenXML docs, and most of the code has been added or refactored under Scanny.
https://python-docx.readthedocs.io/en/latest/
Maybe it was some of Pieter Hintjens writing and/or the C4 process:
* https://rfc.zeromq.org/spec:42/C4/
* http://hintjens.com/blog:112
* http://hintjens.com/blog:106
Edit: oh, as the author mentions a blog post from 2012, it probably isn't any of the above posts (which are newer) but maybe something related to C4.
http://felixge.de/2013/03/11/the-pull-request-hack.html
https://news.ycombinator.com/item?id=5357417
Thanks!
People wanted to implement new things, support new databases, I felt overprotective of the design, but didn't have enough time to bring new contributors onboard. So I just kind of gave up, and that allowed me to think about it from a completely different perspective. If I just deleted it, then I wouldn't care too much about it any more. Giving away the keys was kind of the same, but without preventing others from contributing. And it worked out great.
You can do this with bitcoin, but only drug dealers use that
Wait...
http://gizmodo.com/stop-using-venmo-1759867212
https://jazzband.co/
I updated to 0.9.2d and forgot about it (stopped using the engine), and someone came in with a PR for 0.10.0. I made a couple of notes on the PR, and gave the guy commit access.
He cleaned it up, and has been rebuilding occasionally when new minor versions of the API definitions come in.
The vast majority of people are pretty nice. They aren't assholes. They're just people who have the same issues you had to build the project in the first place, and want to help.
Largely due to my depression and desperate need to get a job, I never got much past an initial read of the EMF+ files, but I'd love to see someone take my branch on git, split it into its own library and then work with someone to integrate it into the Drawing Layer. [2]
1. https://cgit.freedesktop.org/libreoffice/core/commit/?h=priv...
2. https://people.freedesktop.org/~thorsten/talks/fosdem_2014_s...
It basically works via a Command pattern. That's because an EMF is a binary file that consists of a bunch of sequential records. The way it works is that you get an EMF+ file, and you read it from start to finish. Each record you read has a consistent header, and each different type of record does something - or stores an object (such as a pen or font).
My big idea is to use a base EmfAction class that has a function Read() that you use to read each type of record. You use EmfAction::ReadEmfAction() to read the next record from an ifstream, and it moves the file pointer to the start of the next record, and you just loop through the file like this:
https://cgit.freedesktop.org/libreoffice/core/diff/vcl/sourc...
The only snag was how to set state on the DeviceContext - I want the commands to read and store the state, and the DeviceContext should be passed into the command object and be manipulated by it via an Execute(DeviceContext&). But at the time I concentrated on how to read the objects.
Of course, EMF+ has a way of saving a DC's state, allows the DC be modified by subsequent records, and then the DC can be restored, so a stack of DCs needs to be established, but how to do this I'm not rightly sure yet.
I'm pretty certain though that I'm going to need to change the EmfRecord derived command records to start using a constructor where the DeviceContext object is passed in as a pointer.
The header file can be found here:
https://cgit.freedesktop.org/libreoffice/core/tree/include/v...
The record commands are implemented here:
https://cgit.freedesktop.org/libreoffice/core/tree/vcl/sourc...
As it is an initial implementation. The Read() calls are defined in the class declaration. Obviously that will need to be corrected.
The code also probably needs to be rebased, but in all honestly it is such a small change I don't think it would be too hard...
Therefore, I'm extremely hesitant to hand out "commit bit"s again. To make up for it I try and review PRs the day of submission; even then I don't get a lot of contributions.
There seems to be a inherent trade off between security+quality and how welcoming you are to new contributors.
On the other hand, I have taken over maintainership for some projects; but it was after months of steady contributions.
Disowning the project seems like a lose/lose situation.
I still didn't use the project myself; and didn't care enough to fix it, so I just removed myself.
I'm trying to think of a good way to start such a conversation... but it sounds tricky. Probably would depend on the personality of the person. ;)
Unfortunately thats:
- Thats a complicated conversation to have at the best of times. With volunteers over the internet its much harder to organise 1-on-1s.
- A huge time sink. Usually I could make the changes themselves in less time than it would take me to explain the changes to a junior developer. Its especially hard to justify for projects I have in maintenance mode, where I don't want to spend time working on project features at all. Long term hopefully the time investment will pay off, but they'll probably disappear long before then.
- Honestly, its also not that much fun. I contribute to opensource projects because I like making things. Managing people doesn't rub that itch.
I'm not saying I have a better solution. But faced with a stream of mediocre PRs from an enthusiastic new contributor that you don't have time to review, what do you do? Abandoning the project to the new contributor sounds pretty reasonable to me.
There are ways to deal with that, e.g. force small patches that solve well-identified problems; use CI to test; involve projects' users in testing; and above all, to have other maintainers in the project who can catch such behavior and help you fix it. By yourself, you're rather vulnerable.
Ideally you have a core of 2-4 people you trust from previous projects, and then you can bring unknown people in little by little.
There is no tradeoff as such, but you do need to be more sophisticated than "here are full commit rights."
http://sqlitebrowser.org
It was unmaintained on SourceForge for years. Some guys put the code on GitHub and started fixing its problems. I became involved after them (to help on the OSX side initially), then contacted the original author. He was happy to see some people continuing it's development, so he gave us admin on the SourceForge project. That let us cleanly redirect people to the new GitHub project, and it's been growing decently from there (~4,600 stars on GitHub, 3.5Mill+ downloads, etc).
I quickly discovered that a particular piece of software I used daily wasn't really being maintained all that well, despite the fact that there were several contributors listed on its home page. A few dozen bugs reports (some even including patches!) had come in, yet only a few had even been acknowledged.
This seemed like exactly the type of project I was looking for -- something that I used every day and could help improve. I sent an e-mail to the developers stating that I was going to be devoting some time to the project, sending patches in for the bugs, etc., and asking if there was "anything I should know" before jumping in. I spent a lot of time reviewing the previous discussions on the mailing lists, examining their previous commits to see how they did things, and so on.
One of the developers finally replied -- about a week later -- and asked for my SSH key. I sent it to him and he quickly gave me commit access, thanked me for the assistance, yadda yadda.
I closed out umpteen bugs, responded to previously unanswered messages on the mailing lists, and sent patches to the developers list asking for feedback before I committed anything. Having received no responses, eventually I committed all the changes and pushed them into the master branch. Questions that I had to the other developers went unanswered, just like all the previous bug reports and user-submitted patches had.
After a while, I just quit spending any time on it. Perhaps a month after my latest fix, I look at my e-mail one day to see a flood of notification e-mails about commits. The lead developer had reverted every single commit I had made. I was looking for -- expecting -- some explanation but never received one, even after I finally directly asked, "WTF did I do wrong!?".
Nothing. No response, to this day. I eventually said "fuck it", deleted my private key, unsubscribed from the lists, and moved on. I just looked and there are still bugs open today that were open back then.
The sad part is that this piece of software is fairly widespread and a part of all of the major Linux distributions, installed by default on many of them. I think there's been one, maybe two, "releases" in the last five years.
Worked well for a number of projects where developers are jerks and don't allow other talented and dedicated contributors to participate.
As far as I can see:
- 6a4bf69 has not been reverted
- d4a97c5 has been reverted in 8050b2d
- 5f7da05 has been reverted in ccc183d (webmin)
- cf5e9d3 has been reverted in 792a996 (webmin)
- c6634da has not been reverted, he is still listed in debian/copyright.
- 82f8600 has not been reverted (was extended in f24650f)
- 7f8efa8 has not been reverted
- e4f4889 has not been reverted
So, out of 8 commits, 3 have been reverted. The 2 webmin reverts were followed by deletion of the whole webmin file the same day (5785901).
I don't see how three reverts are "a flood of notification e-mails" or that "The lead developer had reverted every single commit I had made."
But I agree that the commit messages of those reverts should have contained a reason.
Obviously something went wrong. But I don't have enough information to call it a dick move.
Hopefully you've found places/projects more receptive to your time/effort since then. :)
I'll probably do something like that again - it would be great if there were a good list of projects that are looking for maintainers.