Hacker News new | ask | show | jobs
by lamontcg 1668 days ago
A lot of the time making a contribution that actually helps means fixing something foundational rather than bolting on another quick bug fix.

That takes work, sometimes quite a lot of it, and there's no trick around getting the work done any easier.

A lot of contributions to open source are simply worth what you paid for them, which is nothing.

Early in a project it is possible to find areas of the codebase where easy things haven't yet been done because there just haven't been enough programmer-hours done yet to burn through the simple stuff. Late in a mature project the easy things have mostly gotten done and finding more easy stuff becomes difficult, and as you pull apart simple looking issues they start to look hard.

1 comments

I often encounter foundational or complex issues (incorrect memory management, deep complexity) when trying to diagnose crashes in open-source apps. And I get frustrated trying to understand deep complexity is frustrating, and maintainers (who haven't looked into the crashes so far, and in one case fixed an earlier crash based on me debugging it for them) don't take it kindly when I complain about the unmanageable complexity and poor stability of these apps. What should I do in this case? Take a break then keep trying? Slow down debugging and spend more time reading and taking notes? Abandon the project, and switch to using/contributing to codebases I find simpler/more cohesive and easier to understand?