from Hacker News

I gave commit rights to someone I didn't know (2016)

by love2read on 5/30/23, 3:55 AM with 159 comments

• by faitswulff on 5/30/23, 1:20 PM

  Counterpoint: gorhill and uBlock. IIRC, gorhill (Raymond Hill), creator of the popular uBlock adblock extension, wanted to step down and hand the reins off to a contributor. The contributor then promptly removed all references to gorhill and started charging for the plugin and turning the extension into an affiliate marketing product.

  This reddit comment covers it pretty well: https://reddit.com/r/ublock/comments/32mos6/_/cte0a3n/?conte...

• by bbbobbb on 5/30/23, 6:09 AM

  I know this is not point of the article but:

  > The PR was bigger than what I felt I could sensibly review and, in honesty, my desire to go through the hours of work I could tell this would take for a project I no longer used was not stellar.

  The PR: https://github.com/django-money/django-money/pull/2/files?di...

  Do others share this sentiment?

  This doesn't look like a particularly big PR to me, judging solely by the amount of code changed and the nature of the changes at first glance.

  Are most of your PRs at work tiny, couple lines of code at most? Am I sloppy for not even consider reviewing this for "hours"? Are all code bases I have worked on sloppy because features often require changing more code than this?

• by sedatk on 5/30/23, 5:37 AM

  Trust goes a long way. Microsoft had given me read/write access to full Windows source code on my first day despite that I was only hired to work on certain parts of the kernel and drivers. I'd never been shown this kind of trust before; other companies I'd worked with always had layers around trust, so, this kind of "you're 100% one of us now" message on my first day had made me extra happy and motivated at Microsoft. I was extra careful protecting source code too. Loved working there until the day I quit.

• by psacawa on 5/30/23, 5:07 AM

  Another possible outcome of "I gave commit rights to someone I didn't know": https://github.com/dominictarr/event-stream/issues/116

• by CapsAdmin on 5/30/23, 7:09 AM

  I've given commit and other "dangerous" access (moderator or admin privileges) to people I don't personally know or barely know for a long time now and I don't think I've ever regretted it.

  My criteria is usually just a willingness to improve the situation. I can observe this over time via pull requests, forks and general community participation.

  I'm very reluctant to give access to someone asking for it. I firmly believe this is something that should be given and not to be expected.

• by kemenaran on 5/30/23, 5:47 AM

  I did this with every first committer to https://github.com/zladx/LADX-Disassembly : giving commit rights immediately (so that they can merge their first PR themselves).

  I did wonders to foster a community of contributors, and get more patches coming. The CI ensures nothing breaks, and there never was any trust incident.

• by kqr on 5/30/23, 5:58 AM

  I think Graeber used to say that if you tell most adults that "Here's your power. I dare you to be responsible with it" they will.

  (The notable exception are people who specifically seek power. Somehow they seem to be the least responsible with it.)

• by verhovsky on 5/30/23, 11:20 AM

  I wanted contribute a fix for a bug that I ran into all the time to https://curlconverter.com/ . The author gave me commit access while I was still working on my first PR (or shortly after) without me asking. I appreciated the trust and I ended up contributing way more than I originally intended to.

• by teekert on 5/30/23, 11:28 AM

  See also [0]. Rutger argues that if you have never trusted someone like this (somewhat) blindly, you may have indeed protected yourself from some misery, but you are also overwhelmingly denying yourself the better parts of life. Because "most people are kind" (which is the original Dutch title of the book btw).

  [0] https://en.wikipedia.org/wiki/Humankind:_A_Hopeful_History

• by dang on 5/30/23, 4:50 AM

  Discussed at the time:

  I gave commit rights to someone I didn't know - https://news.ycombinator.com/item?id=12522654 - Sept 2016 (100 comments)

• by boxed on 5/30/23, 11:08 AM

  My personal rule is that you get commit access after some number of good PRs, depending on the project. Has worked out quite well:

  - instar. I had two guys basically rewrite the entire thing and make it WAY better. I had a good vision for the API but my implementation was pretty bad.

  - mutmut. I would never have gotten windows support going without help. (Although I am thinking of abandoning windows anyway soon...)

  - iommi. This project is much more complex and has a certain philosophy, but we gave commit access to one developer pretty fast as it was super obvious from the first PR what kind of deep thinking he did.

  All in all, great success.

• by jrochkind1 on 5/30/23, 1:31 PM

  These days getting commit rights to inject malware into an already popular gem has become a real threat.

  In 2016 I think it wasn't yet/wasn't recognized.

  I am very sympathetic to the suggestion in OP prior to recognizing that there may be people actually actively trying to abuse your trust to intentionally inject malware.

• by londons_explore on 5/30/23, 7:29 AM

  I've never had giving away commit rights backfire on me.

  And if it did, sorting out the mess and reverting a malicious commit wouldn't be the end of the world.

• by griffinmb on 5/30/23, 5:27 AM

  I created/maintained a popular project for years[^1], and recently passed ownership to someone else. It's been great seeing issues resolve, PRs merge, etc, after languishing for a while :)

  [^1]: https://github.com/nccgroup/sobelow

• by VBprogrammer on 5/30/23, 12:23 PM

  Man I remember having to monkey patch that library to do some caching of the exchange rates. Otherwise it would do dozens of requests for the same information exchange rate.

• by BehindTheMath on 5/30/23, 5:37 AM

  I maintained the pjax library at one point. This is what the author posted at the time:

  https://twitter.com/MoOx/status/955903710617620482?t=BvPIWQ-...

• by mizzao on 5/30/23, 5:14 PM

  Another similar article, "the pull request hack":

  https://felixge.de/2013/03/11/the-pull-request-hack/

• by rorykirchner on 5/30/23, 10:46 AM

  This happened with clojupyter for me. I just gave everyone who submitted something good commit access, and a handful of people who are way better clojure coders than me made it way better in every way.

• by ptx on 5/30/23, 3:59 PM

  If the maintainer of a package trusts everyone on the Internet, then users who trust that maintainer (by installing their package) transitively trusts everyone on the Internet, which they might not have expected if the maintainer didn't declare this position upfront.

  Maybe we need a way to declare in the package and repository metadata that the maintainer considers it world-writable and it shouldn't be installed or updated without very carefully reviewing the code of every new version.

• by ranting-moth on 5/30/23, 6:12 AM

  > Spoiler: trusting your contributors works

  I'm glad it worked for him, but just want to remind people of survivorship bias: https://xkcd.com/1827/

• by riffraff on 5/30/23, 5:53 AM

  I was around around when pugs[0] was a thing, and the "commit bit to everyone who wants it" was kind of magical.

  I am not sure you'd want this for everything, but for quick paced experimental work it seemed to be incredibly effective.

  [0] https://en.wikipedia.org/wiki/Pugs_(compiler)

• by amelius on 5/30/23, 10:58 AM

  Glad it's not the case but that could have worked out very differently for him and all the users of that project.

• by sergioisidoro on 5/30/23, 8:35 AM

  Giving commit rights to some random person is risky, and will only happen to "celebrity" contributors, with enough social validation. That means not everyone will get it, regardless of how good job they do contributing to a fork or proposing solutions.

  So I really appreciate projects like JazzBand [1], that gather likeminded contributors and individuals that want to harbour open source repos around an ecosystem (Eg. Django), while giving some assurance on governance. If JazzBand would be around in 2016, django money would be a very good candidate to be harboured by the org.

  On a meta level, I really would love that more OSS devs would user orgs, rather than personal accounts and repos, so that they can grow their projects with a team, rather than becoming the bottleneck and gatekeeper for development.

  [1]- https://jazzband.co/

• by klntsky on 5/30/23, 9:32 AM

  Strange that all of this happened without a single bit of ongoing communication. I always talk with people continuously whenever there is a collaboration.

• by langsoul-com on 5/30/23, 6:10 AM

  This would be a godsend for a popular repo that's abandoned. But, other packages still use it and they may or may not migrate to a new package.

• by cat_plus_plus on 5/30/23, 4:40 PM

  Careful there, some made one mistake like this and still have to support it 20 years later.

• by IYasha on 5/30/23, 5:59 PM

  Very positive article, thank you! I wish I had similar experience!

• by wly_cdgr on 5/30/23, 6:38 AM

  Glad it worked out that one time, but, could never be me

• by rvba on 5/30/23, 3:40 PM

  Your milage may vary