Developers working together to build shared infrastructure: it’s the fundamental tenet of open-source software. Any motivated programmer with an idea and the ability to implement it can solve a common problem, share the solution with the world, and reap the rewards of future improvements by peer review.

Advancing that shared infrastructure often requires crazy ideas. I should know. In 2005, I created Prototype, the first of a generation of JavaScript libraries designed for building modern web applications. Prototype was based on a far-out idea in a time of stagnant browser innovation: what if we fixed the deficiencies of JavaScript by augmenting its built-in types with new behavior?

The idea quickly took hold. Ruby on Rails adopted Prototype as the JavaScript framework of choice, and before long you could find it powering the web sites of high-profile companies like Apple and the New York Times.

After some time, though, it became clear that Prototype’s core idea was at odds with the world. Browser vendors responded to the JavaScript renaissance by adding new APIs, many of which conflicted with Prototype’s implementation. And developers began to show a preference for small, self-contained, modular libraries over more monolithic frameworks.

In just a few short years Prototype went from best practice to anti-pattern—and depending on who you listened to, you might even be convinced that it was one of the worst things to happen to the web. The reality is that Prototype helped lots of people despite its flawed foundation. But its time had come and gone, and I eventually realized it was time to move on.

It was hard not to take Prototype’s failure personally. Critical blog posts felt like a full assault on my values. And seeing friends use other libraries made me feel like my work was a waste.

But this process is how we move the shared infrastructure forward. In order to advance the state of the art, we have to be willing not only to try new ideas, but to retreat when those ideas prove untenable or when something better comes along. And we have to be able to speak candidly about problematic code without fear of offending the egos behind it.

I have learned that in the open-source world, you are not your code. A critique of your project is not tantamount to a personal attack. An alternative take on the problem your software solves is not hostile or divisive. It is simply the result of a regenerative process, driven by an unending desire to improve the status quo.