Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

He's not resistant to change in the problem space. He's resistant to very particular types of change in one very particular codebase, and for very sound reasons.

He doesn't want to break the ecosystem around curl, which is huge, while getting back to feature parity and compatibility during a full rewrite. Something that comes along and replaces curl externally needn't be completely compatible and therefore is freer to leverage their new, fresh start much more fully. He welcomes a competitor, which means even a possible complete replacement. That's not a resistance to change. That's being very judicious about what one changes and why.



> He doesn't want to break the ecosystem around curl, which is huge, while getting back to feature parity and compatibility during a full rewrite

Very good point! However, rewrite doesn't have to break the existing ecosystem and it can happen in a parallel track right? (curl has had 1.5k contributors so far so the community should have enough support to maintain existing codebase while developing new version on a new programming language hypothetically speaking.)

In fact, I would argue that the "it works now and has been working for 15 years so we don't rock the boat" attitude is negatively impacting the curl ecosystem in the long run. I'm a python developer, a good example I can give you to support my view is the python 2.x to py3k transition (If the "better unicode support" is analogous to "memory safety bug avoidance").

[1]: https://github.com/curl/curl/blob/master/docs/THANKS


Python 2 to Python 3 was basically world-breaking for many projects. Most every non-trivial piece of code needed to be modified to work with 3. Many people maintain older code on 2 to this day even with newer code being written on 3 by the same people.

Is that what you're wanting for curl?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: