Product thinking for open source library design — lessons from a dying project
Posted by krisurbas@reddit | programming | View on Reddit | 2 comments
I spent some time as a core maintainer of web3.js, the original Ethereum JS library, sunset in March 2025, and watched a team of \~9 people lose to viem's team of 2. Not because the tech failed, but because the people running it were bad at product thinking.
I wrote up what I think OSS library maintainers can take from product discipline: https://pckt.blog/b/krzysu/product-thinking-for-open-source-library-design-qzw69a9
Curious if this matches what other OSS maintainers have seen!
GregBahm@reddit
The ChatGPT writing style in this post is like nails on a chalkboard to me. It biases me against anything in the article, even if the information is valuable.
But the premise of the article is weird. "A free open source project should be built like a disciplined commercial product." I can see how that might improve the open source project, but why would someone do the work of a disciplined commercial project without getting paid like they would on a disciplined commercial project?
The logic of contributing to an open source project is "Hey this would be fun." Coding can be fun. Maybe I'll play some puzzle game on Steam. Maybe I'll fuck around on github instead. Maybe a million people will build enterprise software on top of the thing I was doing just for fun.
But disciplined commercial software development isn't fun. That's what the money is for!
thomasfr@reddit
There is of course also the situation where you make something because you need it yourself and just put it out there if someone wants it. I even prefer to not get wide adoption because it takes too much of my time.
Having said that I follow everything under the first headline for more or less anything I make public.