12 ms·
Tech Debt: My Rust Library Is Now a CDO
- manx 3y agoSounds like we need tools to easily inline only the used parts of a library into your project. Does anything like that already exist?
- jasonjmcghee 3y agoIn case I'm not the only one that didn't immediately understand CDO the unexplained acronym - my guess is "collateralized debt obligation" based on multiple uses of collateralized in the post. https://en.wikipedia.org/wiki/Collateralized_debt_obligation https://en.wikipedia.org/wiki/Collateralized_debt_obligation My first guess was "chief data officer".
- cbsmith 3y agoI just realized there's a whole generation of people young enough that they weren't reading headlines back when CDOs destroyed the world's economy. I feel old.
- lanstin 3y agoI came of age during the S and L crisis. Been alternating between increasing prosperity, magical technology, idiotic wars kept going by the side that wants might makes right against the side of people that want an ordinary and beautiful life, and scam based economic collapses, against a backdrop steady worsening of global warming and global biodiversity ever since. Most fascinating life, I hope my kids enjoy their time half as much as I have. Not without problems, but the people, the learning, the flowers, the maths and the holding hands, hard to imagine better, if we’d just get out of our own way.
- jasonjmcghee 3y agoEmbarrassingly, was certainly old enough to be reading those same headlines / being familiar with housing crisis, guess I'm just not an acronym person.
- VHRanger 3y agoThe analogy here is that the CDO is a financial product that's built from other debts. Specifically, it was a piece of partial ownership on a bunch of mortgages in 2008. The issue here is that when the junk mortgages defaulted, the CDO also went sideways [1] In any case, what the author is thinking about is more "systemic risk" (think leftpad or cascading DNS failures) rather than debt-based analogies. One big reason 2008 became such a big mess was the systemic issues, not building products on debt [2] 1. Fun fact - before 2008, they had started making CDOs out of CDOs because of of the insatiable appetite for mortgage-backed financial products. When mortgages are underwritten for people withouth a job, and packaged in a product with a AAA credit rating, it turns out it's a profitable thing to sell. 2. Also the fact that Lehman and Bear Sterns had leverage ratios in the 30x-40x range, which is insane.
- deleted 3y ago[deleted]
- layer8 3y agoI was thinking of https://en.wikipedia.org/wiki/Collaboration_Data_Objects https://en.wikipedia.org/wiki/Collaboration_Data_Objects. ;)
- xeromal 3y agoYou gotta watch The Big Short. That's where I learned what a CDO was
- Ekaros 3y agoI also recommend Margin Call... Then again, I need to put some more thought in analogy where dumping all of it to unsuspecting people would work here...
- xeromal 3y agoI love Margin Call. Jeremy Irons is so good!
- jasonjmcghee 3y agoGreat movie- but didn't remember this acronym.
- jfoutz 3y agoI think they make a joke out of the explanation. Iirc, Margot Robbie explains it, while taking a bath.
- bunnie 3y agoCorrect, with the implication that by creating incentives to bundle junk tech debt into 'AAA' packages (packages with good reputation), the Rust ecosystem is heading for a bubble (and eventually a collapse) because the rating agency that's supposed to regulate things has been gamed.
- mwcampbell 3y agoDo you think that implication is correct? If so, how do we fix it? Of course, companies should pay for what they use, but how do we practically implement that?
- jahewson 3y agoGreat question. One thing to remember is that the value of a piece of software that’s heading towards being un-maintained is much lower than one that has a clear maintenance path. One should be wary of single-maintainer projects. That said, the number of maintainers and the amount of code per maintainer would seem to be the important variables. In this case the code has moved from a repo with one (albeit absent) maintainer to another with one maintainer. Let’s call that neutral. However our new maintainer now has much more code to maintain so the risk has measurably gone up. It might be worth also taking into account how much code in total someone is responsible for across the cargo ecosystem.
- bunnie 3y agoI feel like the analogy does not quite hold because when the junk debt was vendored in, the maintainer actually has more knobs than before to fix the problems - and if it's as easy as bumping some dependencies and fixing a few method signatures, it might actually happen. Whereas in the 2018 crisis, junk debt was rolled into CDOs but there were no 'knobs' the bankers could turn to actually improve the fundamentals of the junk debt. By repackaging the debt they did not get any right to fix the bad actors that made it bad. Things were actually bad, and when it defaulted there was insufficient firewall to prevent the contagion from affecting the encapsulating derivative. Of course it is up to the maintainer but by absorbing an abandoned project, they are actually reducing the amount of unmaintained code, versus simply hiding it. Probably the more accurate analogy to 2018 would be if a private equity firm started a company you could pay to upgrade the rating of an unmaintained Rust package, but no actual change happened and all they did was swap labels on things until the problematic rating disappeared.
- m463 3y agowith 3 XOR operations, I could optimize those Code Default Swaps.
- ramesh31 3y agoThis brings up a great point, that tech debt is literally that; debt. Debt is neither good or bad, it's all down to how you use it. Properly utilized, debt makes things possible that wouldn't be otherwise. And it can be maintained indefinitely, so long as your payments and interest are reasonable.
- margorczynski 3y agoGreat point. Like in real life if the cost of taking that debt is less than what you gain from it then usually it is the right choice to take it. Like going into a small amount of tech debt to ship a critical feature where some people will refactor and rewrite the whole thing not delivering value over long periods which stifles growth. Like it or not but debt is the basis of growth. Of course the issue is like with real debt also - how do you estimate the costs/gains from taking it and you're under risk of going bankrupt if not managed properly.
- xpe 3y agoI agree with "Debt is neither good or bad, it's all down to how you use it.", but this not the central point of the article. The article's differential contribution relative to other bog-standard tech debt articles is thinking about it as derivative. In the financial world, the behavior of derivatives is more complex and less predictable. Here is an excerpt showing the tech-debt-as-derivative metaphor in action: > ... someone called you out of that debt. If we really want to stress the financial terms this is your margin call. Your users demand action to deal with your debt. Remember: tech debt is not "literally" debt. It is a metaphor; a useful metaphor when used mindfully.
- vincnetas 3y agowhat is CDO?
- RicoElectrico 3y agoCollateralised Debt Obligation
- jerf 3y agoCollateralized Debt Obligation: https://en.wikipedia.org/wiki/Collateralized_debt_obligation https://en.wikipedia.org/wiki/Collateralized_debt_obligation
- VHRanger 3y agoIt's a financial product that's built from other debts. Specifically, it was a piece of partial ownership on a bunch of mortgages in 2008. The issue here is that when the junk mortgages defaulted, the CDO also went sideways. Fun fact - before 2008, they had started making CDOs out of CDOs because of of the insatiable appetite for mortgage-backed financial products. When mortgages are underwritten for people withouth a job, and packaged in a product with a AAA credit rating, it turns out it's a profitable thing to sell
- jerf 3y agoWell, whether this is a "win" depends too much on the definition of "win" for me to care to debate. But there are certainly advantages; a vulnerable code path that is never executed and can not be reached from the external library is now a safe code path. A nerve wracking one to be sure, but safe. Another advantage of vendoring like that is that you do have some tools for attacking the code now. If you have solid test coverage on your own library, you can now run your library and run code coverage tools on the newly-vendored library. Fixing the library may be a challenge, but you might be able to just go hacking into it and deleting anything your code doesn't touch relatively easily. Depends on the structure of the vendored library, of course. If you end up deleting all the vulnerable code, you do have a clear win. If you discover you were hitting some of it after all you may end up with an even more clear win. Or, to put it another way, forking a library in general for public maintenance is a big commitment. Vendoring it and hacking it to just the bits you need is much smaller. Even if you don't actually perform this pruning, just the act of making that pruning easier is itself progress. There are disadvantages too, certainly, but it's not all bad.
- leoedin 3y agoThis is actually a great outcome. All dependencies are a security risk - the argument for not vendoring every dependency is that you should keep external dependencies up to date to avoid known security issues. If the external dependency has nobody watching it any more then that argument disappears, and that external dependency becomes a liability. The fact the dependency was marked as abandoned and started getting flagged in security reports is what you want. That lets you make an informed decision about whether to vendor it (which removes the "bad actor sneaks something in" risk) or do something else. It's great that the Rust build system allows that so easily.
- the_mitsuhiko 3y agoAuthor here: the result is now that the debt got absorbed into a project that uses the fork exclusively. It’s less likely that folks will look for security issues. It would in my mind have been better for folks to use an abandoned shared library where at the very least if a security incident popped up we would have all been notified and dealt with it at once.
- psd1 3y agoIs it me, or does rust suffer badly from important functionality being contributed rather than baked in by design, leading to, e.g., multiple incompatible ways to do async? Or am I spoiled by .net, which has an excellent bcl?
- xpe 3y agoBy BCL you mean "Base Class Library"? From where I sit (having worked with many languages in many sectors), BCL isn't an acronym in common circulation.
- coldtea 3y agoNo, but it's an acronym in common circulation in .NET land.
- prmph 3y agoI though rust was supposed to have a vast standard library?
- gbear605 3y agoIt has a large standard library compared to something like C or C++, but it’s small compared to a lot of more recent languages. Intentionally so, since they wanted to be able to create smaller binaries.
- dymk 3y agoThat doesn’t make sense, you don’t link against the entire rust stdlib, you compile directly against its source. You don’t get more than what you call.
- steveklabnik 3y agoYou don’t compile the Rust standard library from source, you link against a pre-built one. There is an unstable option to compile the standard library from source. That said, you’re right that “to keep binary size down” isn’t why the standard library is small. Heck, that you don’t compile from source means sometimes binaries are larger than they have to be, even with LTO! It is largely because anything that’s there has to be supported exactly as is forever, interface wise, and for many things, we did not have the confidence on what the right interface would be. Furthermore, it’s harder to maintain the standard library than it is a package out of tree for a variety of reasons.
- Ah2727 3y ago[flagged]
- maxfurman 3y agoITT: People who have not read or seen The Big Short
- jmchuster 3y agoThe 2008 mortgage crisis is now 16 years old, and the stock market had recovered by 2011. So presumably anyone who entered the work force afterwards might have little sense of it, which would be anyone under the age of 31 (or 35 if you count college).
- inciampati 3y agoOk, but, it's a fork of the code. Not a trade. Can you fork debt? If so, I'm a quadrillionaire.
- imaurer 3y agoI'm excited for the Michael Lewis version of the Rust library ecosystem.
- xpe 3y agoI'm guessing you write this because Lewis "is known for his nonfiction work, particularly his coverage of financial crises and behavioral finance." (Wikipedia) How do you think Lewis would frame up the conversation? Where would he take it? I see much low-hanging fruit; the article linked above isn't exactly lengthy nor rigorous. Detailed analysis of supply chain security probably should include the temporal dynamics; e.g. factoring in automated tooling as well as herd mentality.
- dmw_ng 3y agoit is rumoured Flash Crabs will be out in the fall
- Dowwie 3y agoI like the analogy but when you merge the junk into your repo, it doesn't change in rating but is rather paid in full by you, as you assume it on your own tech balance sheet.
- speed_spread 3y agoRegarding the state of the YAML crate, if you can live with StrictYAML there's always https://crates.io/crates/strict-yaml-rust https://crates.io/crates/strict-yaml-rust
- hiccuphippo 3y agoWoah, nice! This is what I always wanted yaml to be.
- pornel 3y agoIn straightforward terms, author of the most popular YAML parser (https://lib.rs/crates/serde_yaml https://lib.rs/crates/serde_yaml) has suddenly given up on it, and marked it as deprecated and unmaintained, without warning or designating another maintainer. It's not exactly a left-pad situation, because the package remains fully functional (and crates.io doesn't allow deletions), but the package is used in 4000 other crates. Audit and auto-update tools will be complaining about use of an unmaintained crate.
- xeromal 3y agoSometimes you just say fuck it.
- zozbot234 3y ago> Sometimes you just say fork it. FTFY. And vendoring a dependency is really just a hidden fork.
- pengaru 3y ago> FTFY. And vendoring a dependency is really just a hidden fork. It's not a fork until you start diverging from upstream with local modifications.
- mwcampbell 3y agoThat raises the question: what is the current etiquette around deciding whether to pester a dependency's author to include your fixes or just fork it, especially if it looks like you will be the biggest user of that dependency? I'm dealing with that question for a dependency that I want to introduce in one of my crates, but ideally not until at least one of my own fixes is merged.
- foverzar 3y agoObviously fork it, implement your feature, battle-test it, fix and make it more generic, battle-test it again, then ask the maintainer if they would be interested in a pull request. I mean, implementing your fixes in the first place means you are already inherently forking it.
- 0xfffafaCrash 3y agoHave seen the same pattern in the JS npm ecosystem. Npm audit predominantly cries wolf on security issues and rolling things in, license permitting, is one of the most reliable ways of not getting inundated with bogus issues from users (who either don’t understand the context or who don’t care because their employers’ policies around these things was created in a space divorced from reality.) (No, that regex being used as a part of your build pipeline’s transitive dependencies’ codebase is not actually something which can be exploited for a DoS attack.) The ”issues” for deeply transitive dependency can be especially annoying to work around. Trouble is that the way things are structured you often can’t technically establish ”no, we will never enter that codepath so aren’t affected by flaws in it” or ”the only way we enter that codepath is with trusted input in an offline setting”, etc.
- zozbot234 3y ago> Trouble is that the way things are structured you often can’t technically establish ”no, we will never enter that codepath so aren’t affected by flaws in it” And even then, you could enter the problematic paths in future releases as your dependencies update.
- icambron 3y ago> No, that regex being used as a part of your build pipeline’s transitive dependencies’ codebase is not actually something which can be exploited for a DoS attack. Yeah, issues in dev dependencies are such a headache in the JS world. There exist scenarios in which these matter (a compromised build tool injecting malicious code into the lib you’re building) but they are vanishingly rare and hidden under the tidal wave of DOSable regexes that don’t matter at all when you just call them in your build. Couple that with typical build tools having a transitive tree of 50 gabillion dependencies and it’s a real slog. I think the tooling for reporting on these issues needs to differentiate “exploitable if you redistribute” vs “exploitable if you use in a build pipeline”.
- gmueckl 3y agoSlightly tangential, controversial thought: any source based package manager that doesn't enforce a legal right for the registry to forcefully take over maintainance of published packages from their creators is doomed to have awful problems: neglect, malicious change, malicious removal, impostors... If a package is deemed important enough for the larger community, there needs to be a way to rip the package registry entry out of the original owner's hands and to make it point to a fork. Natually, such a move will often involve a lot of drama, but it can actively protect downstream users.
- nerdponx 3y agoThe alternative is the Kik NPM problem. It's bad both ways.
- vaylian 3y ago> any source based package manager that doesn't enforce a legal right for the registry to forcefully take over maintainance of published packages from their creators ... This seems to be a non-issue. The beauty of open source is that you can fork it. The actual issue is that it requires time and effort to maintain an open source project and it's not easy to find someone else who has some time to spare.
- makerdiety 3y agoYeah, finding free labor isn't light work. It's not trivial to externalize costs to unfortunate people. But the entities that succeed in this subjugation are the ones that are rewarded with some substantial wealth and power.
- gmueckl 3y agoNo, there are issues in practice. I have seen many published libraries getting neglected by their creators. Unless the community is actively channeled in this case, the result is a set of lackluster forks by people who only make some random changes. As a potential new user, you don't know what to pick. In the worst case, you need to create another fork, because none of the existing ones fixed the issues you encounter. If you take that public, the mess only gets bigger. This chaos can be reduced with a single "blessed" fork that actively accepts reasonable maintainance patches. There are fewer incentives for competing forks and dependencies (direct and transitive) of the original package can automatically benefit, too, because releases are made under the original package name. This is good because the neglect problem can be several levels deep. There is the issue of manpower. There are two arguments here: one is that the bar for package takeover needs to be set such that community interest in a fork is high enough and the fork needs to be managed by the package registry owner for several reasons. One is that maintainers need to be appointed through the registry provider to keep the nodel functional. Maintainer appointments can be passed on after extended inactivity. The other argument is that a package registry provider puts themselves into a trusted position by default and has to actively maintain that trust. Thus, the burden of managing forks and fork maintainers shouldn't necessarily be seen as inappropriate.
- kosolam 3y agoLol. But really often it’s better to do that and absorb the code in. Not sure what insta is and whether it makes sense in this case.
- jcgrillo 3y agoIs there some way to build a cargo vendor --aggressive which might prune all the code from your deps that is "dead" to your crate? Would it make the "review your deps" problem more tractable? This is a tangent to the article, but related in that ultimately we're responsible for our choice of dependencies and all that entails. It seems like there might be room for tooling to help us better take responsibility for what actually gets compiled into our crates.
- remram 3y agoDo you also go and copy all the bug reports from the library into your own bug tracker? If not, what is the improvement?
- jcgrillo 3y agoThe improvement is (possibly) that not every line of every dependency in the graph actually gets compiled into my artifact. What I want is a tool which trims down my dependencies to just those lines of code which actually end up in my binary. That way I don't actually have to care about (again possibly) most of those bug reports, because they might not have anything to do with the pieces of each dependency I actually depend on. Basically I want something which eliminates all the dead code in my dependency graph, and makes me review the diff in the undead code every time the dependency graph changes, my code changes, or both. Otherwise I'm very unlikely to review my deps and their usage. If it doesn't appear as an actual diff in code review it's not getting reviewed, probably.
- lijok 3y agoYup, you vendor the dependency. I've been doing this for 20 years with basically any dependency that's close to "done" and has slowed down development and maintenance. Having said that, I've not worked in languages where "batteries are not included"
- kunley 3y agoOne disadvantage of merging it into a more successful but also (most probably) bigger project is that it will take even mooooooore time to compile :D
- kunley 3y agoAhh, downvoters got triggered because i touched the holy secret in the Rust religion that's forbidden to talk about xD
- sloowm 3y agoIt would be good if there were some rating agencies that rated the big dependencies and if the government would bale out the packages that became too big to fail. However this means there is need for money. Until companies collectively understand that having a stable base that reaches further than the core language and pay taxes and set up rating agencies all languages will just be a mess of unmaintained dependencies with security issues.
- Night_Thastus 3y agoThis whole situation seems a little ridiculous. If code works and has for years, who cares if it is unmaintained? As long as you don't need to modify it and know its limitations and capabilities, it's fine. Code doesn't go bad on its own. I've borrowed or integrated code from decades ago just fine many times. Personally I'd just ignore any and all complaints about that library and move on.
- zozbot234 3y ago> I've borrowed or integrated code from decades ago Isn't that what the author did by vendoring the library within his own project? It amounts to taking over maintenance for the bits of code you use. Sometimes this is bad (copy-and-paste coding, possibly duplicated effort) but when the third-party component is totally unmaintained it becomes quite excusable.
- nicce 3y agoJust a bigger copy-paste from Stackoverflow than normally.
- remram 3y agoThe answer is of course that it doesn't "work" in a lot of ways. It has accumulated many bugs which will never be patched even though the fixes exist, see https://github.com/chyh1990/yaml-rust/issues https://github.com/chyh1990/yaml-rust/issues and /pulls.
- wooly_bully 3y agoGuess I'm one of the annoying users who complained when armin's Lektor (https://github.com/lektor/lektor https://github.com/lektor/lektor) started going dormant back when, but I loved it for a while. I'm on Astro now, but a big thanks for helping a younger version for me.
- skybrian 3y agoIf it’s a direct dependency, vendoring and then deleting everything you don’t use seems pretty reasonable? This is “a little copying is better than a little dependency.” Make enough changes and it’s not vendoring anymore; you made the code your own.
- alilleybrinker 3y agoIt seems like the RustSec "unmaintained" notice worked as intended. Unmaintained dependencies represent a latent security risk as they will almost certainly not respond to any future vulnerability; identifying this risk before an incident happens is much better than trying to figure out response in the moment during an incident. Armin's answer here, of taking on explicit ownership and responsibility for the third-party code they use, seems like a reasonable and socially desirable response. Yeah, I get that it's annoying, but this is (IMO) pretty much how open source is supposed to work.
- burntsushi 3y agoA latent risk for sure, but this is being handled like an urgent risk because everybody's CI is lighting up. But it's not an urgent risk. So I do not think the system is working as it is intended, although it's hard for me to know exactly what the full intent here. (Since the resulting behavior is likely a confluence of several different systems, so I'm not sure there is one single coherent "intent" per se.)
- alilleybrinker 3y agoYeah, I'd put the blame for that on the tools / systems which consume and report this kind of vulnerability data. They (at least as far as I've seen) don't really differentiate between severities of vulnerabilities. On the one hand, a strong preference toward "just patch" for vulnerabilities can make a lot of sense (the more that mechanism is flexed, the better it moves when you really need it, and rapid integration of fixes reduces time for exploitation by attackers), but here it's applied to a maintenance notice that ought to be treated a little differently. Nonetheless, I think RustSec's feed is working as intended, and I'd put the expectation on the consuming tools (including `cargo-audit`, which I believe is largely maintained by the same people that maintain the RustSec vulnerability database) to change.
- keybored 3y ago> Armin's answer here, of taking on explicit ownership and responsibility for the third-party code they use, seems like a reasonable and socially desirable response. It seems like he vendored it in order to avoid the useless alarm bells going off. Don’t we have a `Cargo.lock`? Just keeping the status quo seems fine. But other people didn’t like it because of these automated alarm bells, hence it becomes “socially desirable” to do something that doesn’t materially make a difference.
- munificent 3y ago> Now that junk tech debt is suddenly rated “AAA”. I think by "suddenly", the author is saying it doesn't make sense for the same code to have a better debt rating when vendored than it did before. But that's only looking at the value of the code itself, which misses the most important part of the total value proposition. When a maintainer vendors code in, the maintainer owns that code now. If you're an active maintainer vendoring in code from a dead project, you are increasing the value of that code because now there is an active human who may respond to issues, review pull requests, and fix bugs. By another analogy, giving a neglected pet to a new owner increases the value of the pet because it will be better taken care of, healthier, live longer, etc.
- epage 3y agoOnly for those who use the dependency indirectly. This will likely see very few eyes to find bugs. The maintainer will also have a ramp up in having to deal with a large, unfamiliar code base that will be a hindrance to implementing fixes or reviewing them.
- munificent 3y agoYes, it places a burden on the maintainer, but that's exactly why it increases the value of the code. That burden is the maintainer providing that value.
- nindalf 3y agoSomewhat fortuitous that someone already forked yaml-rust and rewrote it in pure Rust to create yaml-rust2 (https://github.com/Ethiraric/yaml-rust2/blob/master/documents/2024-03-15-FirstRelease.md https://github.com/Ethiraric/yaml-rust2/blob/master/document...). Pretty cool that the fork fully passes the YAML test suite as well and is more performant on benchmarks. The migration appears straightforward too. Ultimately, the problem remains - we're dependent on the work of others who are happy to provide us with free labour for now, but may not be in perpetuity. I don't know that there's a way around that other than compensating them for their time and effort and hope they continue their good work.
- masklinn 3y ago> Somewhat fortuitous that someone already forked yaml-rust and rewrote it in pure Rust to create yaml-rust2 yaml-rust was a pure-rust implementation, that's literally in the tagline: > A pure rust YAML implementation. serde_yaml was arguably less pure-rust, as it relied on unsafe-libyaml, which is a c2rust translation of libyaml.
- Cheer2171 3y ago> I don't know that there's a way around that other than compensating them for their time and effort and hope they continue their good work. Any project with a bus factor of 1 is inherently dangerous and risky. On a long enough timescale, the probability that an open source maintainer will quit their project is 1. The only way around that is to make solo-maintained projects taboo.
- Zuiii 3y ago> I don't know that there's a way around that other than compensating them for their time and effort and hope they continue their good work. For me, the go-to solution for this problem is to avoid third-party dependencies as much as possible. This is probably not an option for rust project given how anemic the authors of Rust's standard library want their library to be, but it is definitely an option when using other languages with fully featured libraries. I rarely use external libraries (other that database drivers) because I deliberately work with languages that have all the things I need built in.
- umvi 3y agoPSA: you basically have to have seen the movie "The Big Short" to understand the analogy in the article. Or at least this scene: https://www.youtube.com/watch?v=xbiDrzTd8fE https://www.youtube.com/watch?v=xbiDrzTd8fE
- mwcampbell 3y agoIf we're going to use financial analogies, we should also address the elephant in the room: actual money, that is, paying maintainers. I've just filled out the contact form at Tidelift, even though it may practically be too expensive for my tiny bootstrapped SaaS company. I'm open to other ideas.
- dmitrygr 3y ago> you just merge that code into your own library License-permitting, right? right?
- steveklabnik 3y agoThe Rust ecosystem is nearly uniformly Apache2/MIT, so this is more likely than not.
- keybored 3y agoSo GitHub is apparently so bad at presenting repositories and forks that there are busy beavers running around asking “is this maintained” and reporting to some registry or something if they apparently aren’t. - Anyone know this guy? - Has he logged on in the last year? - Can someone contact his aunt in Xinjiang? Maybe she knows something I experienced the same thing with a repository that wasn’t active. I mean a repository might be feature complete so why should it be active? Well other people wanted more from the repository. But not the author apparently. That’s fine. Well turns out that there was an active fork which was vastly more “featureful” by design. And a PR to that repository took less than three hours to be merged. How did I find that fork? Honestly I think it was mostly by coincidence since I saw the fork owner posting on some issue in the original repository. Spacemacs was experiencing a reviewer bottleneck for a while (I don’t know what the status is now) in part because the repository owner was not very active. That got partly solved by more people getting commit rights apparently. But why don’t forks pick up the slack instead of waiting around for commit rights? Hijack the PRs and review them in your own forks. Merge them if they are good. Then come back to the upstream and ask the main guy to merge them. If he trusts you and would have given you commit rights anyway then it shouldn’t be a problem. GitHub should prominently tell you about other forks if they are notable in some way: - More activity (most important) - Maybe more stars Because then you don’t have to hope to God that the repository owner logs on every two weeks and keeps his thirty repositories updated about their maintenance status. (Honestly who doesn’t have dusty old code that works for them which you haven’t even thought about for months or years?) Why is this so difficult? All repositories are peers after all.
- pests 3y agoI don't think this has anything to do with GitHub?
- frays 3y agoGreat analogy and post.
- christoff12 3y agoI really enjoyed the analogy.
- mdnahas 3y agoAs a former quant and now economist, I want to congratulate the author on correctly using the term Collateralized Debt Obligation! That is a great metaphor for what they’ve done. I do want to write an article on “technical debt” at some point. “Debt” is not a great metaphor for the concept. Maybe “high viscosity code” might be better? The code cannot be changed easily to accommodate new features, so it feels like it has a high derivative. Debt is something else completely.
- richrichie 3y agoIn some sense, these issues are like being short OTM puts that blow up in your face in a surprising way. Debt is effectively a short OTM put :)
- alecco 3y agoAnd we are back to square one. Cathedral has its benefits over Bazaar.