[avodonosov]

Yes, Microsoft is good at backward compatibility.

So many open source hackers do not know the basic tecniques for backwards compatibility (e.g. don't reaname a function, just intoduce a new one, leaving the old available).

I'm spending very significant efforts maintaining an OpenSSL wrapper because OpenSSL constantly remove / rename functions. I hoped to branch based on version number, but they even changed the name of the function which returns version number.

And that's only one example, lot of people do such mistakes costing huge efforts from users.

And this popular semantic version myth, that you just need to update major version number when you chane the API incompatibly to save your clients from trouble.

[ben0x539]

> So many open source hackers do not know the basic tecniques for backwards compatibility (e.g. don't reaname a function, just intoduce a new one, leaving the old available).

I'd dispute this, or at least I think this doesn't capture the whole picture. Microsoft makes money with backwards compatibility and can afford to spend significant effort on to the ever-growing burden of remaining backwards-compatible indefinitely. Open source volunteers are working with much more limited resources and I think that it comes down much more to intentional tradeoffs between ease of maintenance and maintaining backwards compatibility.

If you have a low single-digit number of long-term contributors, maybe the biggest priority to keep your project moving at all is to avoid scaring off new contributors or burning out old contributors, and that might require making frequent breaking changes to get rid of unnecessary complexity asap. Characterizing that as "they don't know that you can just introduce a new function" doesn't seem like it yields instructive insights.

[avodonosov]

Yes, this is exactly the wrong reply I often hear when complaining about backwards compatibility.

The mistake here is that in 99% of cases backwards compatibility costs noting - no efforts, no complexity.

Of two equally costing choices the people breaking backwards compatibility just make a wrong choice.

> maybe the biggest priority to keep your project moving at all

When you rename function SSLeay to OpenSSL_version_num, where are you moving? What does it give to your project?

Ok, if you like the new name so much, what prevents you from keeping the old symbol available?

        unsigned long (*SSLeay)(void) = OpenSSL_version_num

(Sorry for naming OpenSSL here, it's just one of many examples)

When developers do such things, they break other open source libraries, which in turn break other. It's a huge destructive effect on the ecosystem. It will take many man-days of work for the dependent systems to recover. And it may take years for the maintainers to find those free days to spend on recovery, and some projects will never recover (e.g. no active maintainer).

With a lift of a finger you can save humanity from significant pain and efforts. If you decided to spend your efforts on open source, keeping backwards compatibility by making the right choice in a trivial situation will make you contribution an order of magnitude bigger, efficient.

So, I believe people don't know what they are doing when they introduce breaking changes.

[avodonosov]

I saw developers introducing breaking changes, then finding projects depending on them and submitting patches. So they really have good intentions and spend more their volunteer open source energy than necessary. And when the other project can not review and merge their patch (no maintainers) they get disappointed.

So please, just keep the old function name. It will be cheaper for you and for everyone.

[pnutjam]

An unmaintained duplicate way of doing things is a mistake waiting to happen.

[jammygit]

I was just thinking this, but I guess were really just talking API changes. Everything under the api can still get rewritten, no?

[jasonkester]

Microsoft makes money with backwards compatibility

That's a good way of putting it, and it gets to a key difference between open source and proprietary software.

In the open source world where a million eyes make all bugs shallow, developer hours are thought of as free. So if you change something it's no big deal because all the developers using your thing can simply change their code to accommodate it. It doesn't matter how many devs or how many hours, since the total cost all works out to zero.

In the proprietary world, devs value their time in dollars. The reason they're using your thing is because it's saving them time. They paid good money because that's what your thing does. Save time. Get them shipped. As a vendor, you're smart enough to realize that if you introduce a change that stops saving your customers time or, worse, costs them time or, god forbid, un-ships their product, they'll do their own mental math and drop you for somebody who understands what they're selling.

In the end, all we're talking about here is the end product of this disconnect in mindset.