2 ms·
I’m not meaning to make a case for monkey patching per se, but it’s interesting that the major points in this article are actually just points against forking a
by swatcoder 4y ago
I’m not meaning to make a case for monkey patching per se, but it’s interesting that the major points in this article are actually just points against forking and patching open source code at all.
The Stallman-era idea of taking possession of your own copy of open source code so that you can do with you want with it, is now being argued to be too dangerous for you.
You should just trust the upstream team, just like you would with proprietary software, and if you reaaally need something custom, you should let them take a look at your idea in a PR and they’ll decide if it’s a good idea that can be merged when they’re ready to schedule it in.
When you look at the security risks and developer talent at play today, you can understand why this argument makes some sense. But if you’ve watched or been part of the of the Open Source Revolution, you kinda have to laugh at the irony.
- lmm 4y agoI don't see any conflict - I don't think Stallman has anything against sharing improvements and developing together. If anything the old-school FSF development model was more centralised (see The Cathedral and The Bazaar). If you have access to the source you can understand it and fix bugs in it; that's true whether you apply them locally or submit them upstream.
- hprotagonist 4y agoIn fact, RMS advises (heh) against advising core emacs functions in elisp; which is more or less monkeypatching. https://www.emacswiki.org/emacs/AdviceVsHooks https://www.emacswiki.org/emacs/AdviceVsHooks
- tadfisher 4y agoHe specifically said that about code in Emacs itself, and only insane people would disagree with that position when you can just change the original function. IMO, and I suspect RMS would agree: defadvice shouldn't be used in code you distribute to others, because multiple pieces of advice can conflict, and the code defining the advice doesn't control which advice is loaded first. It is still a valuable tool for usage in personal configuration and for prototyping.
- neandrake 4y agoCould you give an example? Most of the arguments in the post seemed to be focused on long-term maintenance. It does put a lot of faith in the upstream allowing contributions and making good decisions, especially when viewed through the lens of Ruby/Rails a belief that upstream continues to exist. To me though some of the arguments like submitting fixes is actually encouraging the reader to fork and make their own changes as opposed to using dynamic modification to behavior.
- llanowarelves 4y agoMaintenance costs as time goes on can be expensive.. at least relative to 0 maintenance cost. With a lean team it feels bad.