OSS + ELC EU 2026

Most first contributions fail before the code does. They try to solve too much, touch too many files, and stall in review while the maintainer waits for a smaller entry point that never comes.

Adding HTTPS support to proxy-chain, a Node.js proxy library used across the web-scraping ecosystem, taught me this the hard way. My first attempt was comprehensive: tunnel support, byte accounting, certificate handling, the works. It went nowhere. What merged was a version that did one thing and stopped.

We'll use that contribution as a case study in scoping. The technical context matters, because it's a great example of hidden complexity: TLS changes proxy semantics in ways that aren't obvious until you're counting bytes and realising the handshake traffic your code never sees is inflating every number. But the talk is really about the decisions behind the code - how to identify what "done" looks like before you start, how to read a maintainer's priorities from their issue tracker, and how to negotiate a PR boundary that gets merged rather than praised and ignored.

You'll leave with a framework for scoping contributions that ship, and a clearer sense of when doing less is the right call.