Talking with Steve Sanghi, CEO of Microchip for 31 years

[zilp]

And yet, i have a friend that works with STM32 and making good money on it. He uses Keil and doesn't want to touch anything anymore that has eclipse or GCC.
i sort of agree with him. Free stuff is nice for your personal projects because it's your hobby, or when you want to get your feet wet with new things.

Somehow the interesting part is missing from this comment, isn't it? I.e., *why* he doesn't want to touch anything that has eclipse or GCC, and *why* you agree with him.

The fact that free stuff is nice for hobby use and the like ... doesn't say anything about whether it isn't nice for professional use, does it? And the mere fact of having to pay money obviously can't be the advantage, can it?

[EEVblog]

Dave's right to some extent; I could, in the near future, just rent it again for each update, and add the cost to my bill. But that assumes that the same month-by-month licensing terms are still available when the code needs updating a couple of years later. I don't want to risk discovering that a couple of hours' worth of software tweak also needs a four figure sum spending on a compiler, because <insert excuse about middle managers at Microchip here>.

Assuming you absolutely need the highest optimisation level. Otherwise just use the free version. Or if you prefer a perpetual paid tool, there are third party compilers you can buy.

[EEVblog]

If you are the most profitable microcontroller company in the business and everyone else is falling over themselves to offer free tools, then perhaps it's not a smart move to join a race to the bottom.

If you are the most profitable microcontroller company in the business and everyone else is falling over themselves to offer free tools, then perhaps it's not a smart move to ignore changes in the market.

I mean, that's just a truism, isn't it? *Perhaps* it's not a smart move to do the same ... *perhaps* it is.

Exactly, you don't know, so why criticise them for continuing to do what has demonstrably worked well for them?
You don't have to like it, and that's fine, feel free to chose another vendor. But I see the criticism here as just personal desires to get it for free just because many others do it, rather than a valid business argument.

[hans]

But I see the criticism here as just personal desires to get it for free just because many others do it, rather than a valid business argument.

Free as in free beer, or free speech?

The free-beer compiler (without optimizations) is plenty for what it does. And if more is needed, the paid compiler is reasonably affordable. From a business perspective this is the easiest calculation to make. However, as I stated, I doubt whether it's of much value to sell a few k$ (max) of licenses to customers that buy literally tens of k$ of chips.

But you cannot pay to get the free-speech away. If one is happy with a closed ecosystem, then that's fine. But for engineers that puts down certain requirements (like C++ support in a 16-bit project, or newer compiler features for 32-bit parts), then it removes Microchip's PIC parts as a potential candidate. A business isn't as quickly going to fuss around with unofficial XC16 compiler builds or manually pulling MIPS GCC from upstream. Those open source projects are too unmaintained as of now to be worth the time.

I think this discussion is largely a hardware vs software engineering perspective. In hardware world, every tool costs money, and dare I say that not every hardware engineer likes to spend a ton of effort/research on the most sensible tools that can be used in the long run. So an "all-in-one" package is arguably best for those use-cases. In the software world, every developer keeps a close eye on any dependency a project has to include. Engineering debt in software under active development is a huge burden. And these include the tools being used alongside large libraries or frameworks.
I regularly read stories here about spinning up old VMs to continue working on an old embedded firmware project. Those are the horrors of needing legacy compiler versions that only work on EOL operating systems.

Probably no company roadmap is going to give a rat's ass about academia, but in many of the papers that I read, I seldomly see a PIC part being used. The last one I saw was from 2016, where a PIC12F was programmed to serve as an OOK wake-up radio. I find this fascinating, as I'm sure that PIC is/was a very popular part family used in education, and probably the first MCU that many learned to program on (e.g. a PIC16F84, PIC16F877 or PIC16F628A). But that is many moons ago. From what I can see, MSP430 is incredibly popular, but so is AVRs (even used in the Arduino form factor), ARM (in particular STM32) and ESP32's. Now AVR is part of Microchip so that's their slice of the cake; but I think that success can be largely contributed by the works of the pre-Microchip era, and in particular because of projects like Arduino, avrdude and avr-gcc. Atmel always gave good vibes to the people that liked writing firmware, even 1 - 1.5 decade ago.

But at this point I'm making arguments out of sentimental value, and indeed, that's of no use in doing business. I just meant to say that these "free-speech" choices often steer away people from using PICs (again).

[zilp]

[If you are the most profitable microcontroller company in the business and everyone else is falling over themselves to offer free tools, then perhaps it's not a smart move to ignore changes in the market.

I mean, that's just a truism, isn't it? *Perhaps* it's not a smart move to do the same ... *perhaps* it is.
 

Exactly, you don't know,

That's not what I said, though. I just showed why your argument doesn't say anything substantive, not that I don't know.

so why criticise them for continuing to do what has demonstrably worked well for them?

I am not criticizing them, I am simply explaining why I think that it's a bad business decision. And also, it absolutely has not demonstrably worked well for them. That's what I am trying to explain to you: The fact that some business is doing X and that that business is successful, says just about nothing about whether X is what makes them successful. At best, it says that X isn't bad enough to make the business fail, that's it.

This error in reasoning is also more formally known as cum hoc, ergo proper hoc, see also https://en.wikipedia.org/wiki/Correlation_does_not_imply_causation.

You don't have to like it, and that's fine, feel free to chose another vendor. But I see the criticism here as just personal desires to get it for free just because many others do it, rather than a valid business argument.

Well, but then you are simply ignoring my (and others') explanations as to why this seems economically questionable, while at the same time inventing a supposed desire on my part to get their software for free? That doesn't mean that I didn't make those arguments, and it also doesn't mean that I actually desire to use their software, for free or otherwise.

Your counter so far boils down to "they are successful, therefore, whatever they are doing can be assumed to be a good business decision" ... which just is an incredibly weak argument, both as a matter of logic, but also evidently, given that plenty of once (longtime) successful businesses have managed to fail, and often to fail spectacularly, which obviously means that quite regularly successful businesses at some point do indeed do things so horribly misguided that they end up ending the business, and thus, obviously, there must be way more cases where similarly successful businesses make decisions that hurt them, to some degree or another, but not quite bad enough to make the whole business come down.

I.e., it's just completely normal for successful businesses to make bad business decisions, while being and staying successful ... just not as successful as they would be if they had decided differently.

[EEVblog]

[If you are the most profitable microcontroller company in the business and everyone else is falling over themselves to offer free tools, then perhaps it's not a smart move to ignore changes in the market.

I mean, that's just a truism, isn't it? *Perhaps* it's not a smart move to do the same ... *perhaps* it is.
 

Exactly, you don't know,

That's not what I said, though. I just showed why your argument doesn't say anything substantive, not that I don't know.

so why criticise them for continuing to do what has demonstrably worked well for them?

I am not criticizing them, I am simply explaining why I think that it's a bad business decision. And also, it absolutely has not demonstrably worked well for them. That's what I am trying to explain to you: The fact that some business is doing X and that that business is successful, says just about nothing about whether X is what makes them successful. At best, it says that X isn't bad enough to make the business fail, that's it.

This error in reasoning is also more formally known as cum hoc, ergo proper hoc, see also https://en.wikipedia.org/wiki/Correlation_does_not_imply_causation.

You don't have to like it, and that's fine, feel free to chose another vendor. But I see the criticism here as just personal desires to get it for free just because many others do it, rather than a valid business argument.

Well, but then you are simply ignoring my (and others') explanations as to why this seems economically questionable, while at the same time inventing a supposed desire on my part to get their software for free? That doesn't mean that I didn't make those arguments, and it also doesn't mean that I actually desire to use their software, for free or otherwise.

Your counter so far boils down to "they are successful, therefore, whatever they are doing can be assumed to be a good business decision" ... which just is an incredibly weak argument, both as a matter of logic, but also evidently, given that plenty of once (longtime) successful businesses have managed to fail, and often to fail spectacularly, which obviously means that quite regularly successful businesses at some point do indeed do things so horribly misguided that they end up ending the business, and thus, obviously, there must be way more cases where similarly successful businesses make decisions that hurt them, to some degree or another, but not quite bad enough to make the whole business come down.

I.e., it's just completely normal for successful businesses to make bad business decisions, while being and staying successful ... just not as successful as they would be if they had decided differently.

I honestly don't care that much to argue it. I just understand Sanghi's answer and don't have a problem with it. I think it sounds quite a reasonable explanation actually.
And given that he very successfully ran the company as CEO for 31 years, it's likely he has a tad better insight than us punters.

[madires]

I regularly read stories here about spinning up old VMs to continue working on an old embedded firmware project. Those are the horrors of needing legacy compiler versions that only work on EOL operating systems.

And with the upcoming EU regulation for product lifetimes we'll experience more of that. But the problem is much bigger than just compilers. There are tons of legacy systems which are configured/programmed via proprietary programs, e.g. PBXs, network elements, all kinds of controllers and so on. In many cases the manufacturer stops updating the configuration program after a few years (it doesn't generate profit) and then you need a VM with WinXP to be able to run the old configuration software in order to change a ring group in the PBX. I could tell you also a lot of horror stories with Java based config tools requiring the setup of a dedicated environment. In other cases the configuration software is well maintained but suddenly drops support for older devices. Proprietary software can become a large liability in the long term.

[zilp]

I honestly don't care that much to argue it. I just understand Sanghi's answer and don't have a problem with it. I think it sounds quite a reasonable explanation actually.
And given that he very successfully ran the company as CEO for 31 years, it's likely he has a tad better insight than us punters.

Well, he probably has a better insight into the inside of the company, which is why I agree with hans' observation that this sounds like "internal managerial side-effect that's exposed to the outside world".

Whether he has a better insight into the market, and in particular into potential customers who aren't (yet), doesn't seem quite as obvious. After all, a common way for businesses to fail is that they fail to adapt to changes in the market, where they continue to serve established customers well, but fail to notice cultural or technological shifts in sections of the market that they thus lose to competitors, only to notice the problem once a significant portion of their potential future customer base is already comfortable in somene else's ecosystem while their established customer base dies off, or, in a business context, retires.

I mean, not that I am seeing Microchip going under any time soon, as they obviously have other strengths, and this particular limitation also isn't all that bad, all things considered, plus, quite a few of their chips can work with free (as in freedom and as in money) toolchains just fine, with the most obvious one being all the Arduino stuff that they effectively acquired with Atmel ... but, yeah, I am not convinced that this in particular is a good business decision, nor that his explanation makes a whole lot of sense, other than possibly showing an internal problem with their management when the CEO can't prevent what he considers a bad business decision (i.e. closing down or splitting off the dev tools department) other than through the convoluted construct of trying to make them a profit center. I mean, that would make more sense as a strategy if the department head tried to prevent a hare-brained CEO from closing down the department, but not really this way around.

[peter-h]

And with the upcoming EU regulation for product lifetimes we'll experience more of that.

I am 100% confident it will have no effect whatsoever. Really easy workarounds. Brussels loves to boast about their "consumer champion" stuff but most of it passes by.

Also such companies will find dev recruitment hard because this is a CV killer

Proprietary software can become a large liability in the long term.

It always was but lots of people don't care. If you work for a company as an employee, you have absolutely no interest in futureproofing anything.

where they continue to serve established customers well

Does Microchip have large OEM users? For example car manufacturers? A mfg can look after those people really well while being ritually hated on forums

I work above a KIA service centre and the other day opened up an old ECU box. It had some chips from Siemens which I have never heard of anybody using. Well, KIA bought a few million

[globoy]

There's absolutely no denying Steve and Microchip's success.  But I wonder if some of the decisions around tools become a liability in the long haul.  We've all seen how a once dominant company can refuse to change with the times and then find themselves in trouble.  Here's another opinion, for what it's worth 

Microchip seems to have a lot of parts designed into deeply embedded systems that probably don't change for a long time. For example automotive components or medical devices.  And these are large volume items that generate a lot of revenue.  And it's probably easy for the manufacturers to evolve their Microchip based designs for different generations of products, at least up to a point (for example when fundamental things change like vehicle communication busses).

But the development world has changed.  It seems to me that a couple of decades ago the PIC was the *it* processor family.  It was everywhere and designers could easily get their feet wet with a huge number of cheap development boards and programmers.  Lots of programming was done in assembly and Microchip's tools for that were free (many competitor's tools were not free at that time).  There were BASIC interpreters and even a choice of C compilers.  Super easy to become proficient with the architecture(s) and there were lots and lots of people with experience.  I'd guess that led to a lot of design ins. 

But over time it seems that the general development world moved on.  Arduino came into the picture.  Microchip tools became much more pricey at the same time other competitors started offering free tools.  And open source provided even more flexibility.  Now one rarely hears about PIC generally.  It seems to have much less mindshare.

As someone who has done a lot of embedded system design, including with PICs, I'd say that I found it less desirable to use Microchip products over time and it doesn't entirely have to do with the cost of a compiler (because it's generally a small part of the overall development cost).  The transition to MPLAB-X, while allowing cross platform compatibility - resulted in a more klunky, slow, bloated IDE experience.  And some of Microchip's debug programmers like the ICD 3 and 4 are persnickety pains-in-the-ass.  During this time other vendors - like Silicon Labs - started offering Keil compilers for free in their IDEs which were based around Eclipse and somewhat less painful to use than MPLAB-X.  And many people wrapped GCC or other open source tools into mostly polished solutions.  It's easier than ever to learn about other micros which is a big part of them getting a design in.

All this makes me wonder if future long-life designs are being created with micros not from Microchip and although Microchip has done well and is doing well now, it may have a problem in the future.

[schmitt trigger]

I don't know of any 4-bitters, but they did the AY-3-8910 sound generator which was very popular. The only dead-end processor I'm aware of was the CP1600, a 16-bit PDP11 clone.

General Instrument’s another big claim to silicon fame was the AY-3-8500 all-in-one video game IC.
A truly revolutionary IC.

[nctnico]

I honestly don't care that much to argue it. I just understand Sanghi's answer and don't have a problem with it. I think it sounds quite a reasonable explanation actually.
And given that he very successfully ran the company as CEO for 31 years, it's likely he has a tad better insight than us punters.

Well, he probably has a better insight into the inside of the company, which is why I agree with hans' observation that this sounds like "internal managerial side-effect that's exposed to the outside world".

Whether he has a better insight into the market, and in particular into potential customers who aren't (yet), doesn't seem quite as obvious. After all, a common way for businesses to fail is that they fail to adapt to changes in the market, where they continue to serve established customers well, but fail to notice cultural or technological shifts in sections of the market that they thus lose to competitors, only to notice the problem once a significant portion of their potential future customer base is already comfortable in somene else's ecosystem while their established customer base dies off, or, in a business context, retires.

You and globoy are touching a good point here. I also noticed that PIC is mentioned far less often than it used to be during the last few years on this forum. Most seem to evolve around STM32 nowadays. I don't see customers using PICs in new designs either. And let's not rule out relative newcomers from China. Recently I have been dabbling a bit with the ESP32 and it has a really extensive ecosystem to support it with a lot of things that simply work as advertised out of the box. A while ago somebody made the point that the ESP32 is very interesting as a general purpose microcontroller due to the price point even though it doesn't have that many I/O pins. Where do you get a microcontroller with dual core >200 MHz, 8MB of flash and >400 KB of RAM for 5 dollars?  It's borderline insane...

OTOH, Microchip has been acquiring quite a few companies that server either a high-end niche market (Microsemi), Atmel as a well established maker of cost effective flash chips and the likes of SMSC (low quality networking chips) that gives Microchip a rather diverse & broad portfolio. They might not even need the PIC microcontroller line in order to be profitable.

[EEVblog]

Whether he has a better insight into the market, and in particular into potential customers who aren't (yet), doesn't seem quite as obvious. After all, a common way for businesses to fail is that they fail to adapt to changes in the market, where they continue to serve established customers well, but fail to notice cultural or technological shifts in sections of the market that they thus lose to competitors, only to notice the problem once a significant portion of their potential future customer base is already comfortable in somene else's ecosystem while their established customer base dies off, or, in a business context, retires.

Business can also fail (or begin a downward spiral) when they think they need to change because everyone else is, and they end up throwing away their winning ticket.
Reminds me of another thread happening on here right now about how Fluke haven't updated the 87V in over 20 years. And just before that they tried to change things with the 87IV and realised very quickly that was a mistake, so they renamed it the 189 and stuck with the 87V for the next 20 years.

[EEVblog]

OTOH, Microchip has been acquiring quite a few companies that server either a high-end niche market (Microsemi), Atmel as a well established maker of cost effective flash chips and the likes of SMSC (low quality networking chips) that gives Microchip a rather diverse & broad portfolio. They might not even need the PIC microcontroller line in order to be profitable.

I doubt that. Like he said, practically every medical device has a PIC in it, and that's a big part of the reason why their business boomed during covid. But of course that also had the unintended consequence of the medical market gobbling up all the stock and production capability.

[EEVblog]

I do agree that it might be a smart play to actively target the low end players and hobbyists again with the full tools for free in that space, or some other incentive.
But there are now so many players in that space, the horse might have bolted.
I really like the Microchip factory programmed service option. Not sure how many other players have that service radily available for everyone?

[SiliconWizard]

One big error many seem not to completely grasp - until they themselves run a business in a very competitive environment - is to do just exactly as everyone else does, because that's what seems to please the majority, and think this will make a viable business. You usually want to find your niche, even if it's a big one, rather than stick to the lowest common denominator waiting for your tiny share, if there is any left and if you're lucky.

As he said, that was part of the reason they chose MIPS over ARM.

Generally speaking, from the POV of the customer, the "ideal" company making "ideal" products is often pretty different from what makes profits.

[hans]

Good point. The business is still doing incredibly well, so I cant fault the leadership. But as a 'free speech' geek, I just wish it would do a bit more sometimes

Steve's rationale about RISC-V is also one I agree with. Its a nice processor architecture with a great future, but perhaps for FPGAs and HW designers and not in user-programmed/facing SoCs. The extensability and freedom of the ISA means it can make things less predictable for the end user (programmer).

That seems to fit exactly in Microchip's main point they excel at: simplicity and getting the job done. Factory-programming for low volume orders or programmer on the go in a <100$ PICKIT. Their docs are good and don't require an university degree to understand how the CPU starts executing code and what it is doing. Their peripherals are still managable by a single person to develop drivers for. The same cannot always be said about STM32s or ESP32s .. So in that regard they support the small developer very well.

[zilp]

Business can also fail (or begin a downward spiral) when they think they need to change because everyone else is, and they end up throwing away their winning ticket.
Reminds me of another thread happening on here right now about how Fluke haven't updated the 87V in over 20 years. And just before that they tried to change things with the 87IV and realised very quickly that was a mistake, so they renamed it the 189 and stuck with the 87V for the next 20 years.

Well, sure ... but then, it doesn't seem particularly likely that Microchip has customers who use Microchip processors *because* the dev tools cost money, does it?

Like, it doesn't seem like a particularly useful analogy to me to point to a company effectively discontinuing a successful product and replacing it with a different product that then potentially doesn't have the features/qualities/whatever that are the reason why customers bought the discontinued version to explain why it might be a bad idea to provide dev tools for free, given that it would seem rather unlikely that any customer has in their purchasing requirements that dev tools must cost a minimum amount X for the chips to be considered for a design.

I mean, you are effectively arguing that businesses shouldn't reduce prices because a sufficiently high price could be the quality that customers are choosing the product for ... which might be true for status symbol stuff, but so far I haven't seen a purchasing department that tried to find the most expensive source for electronic components to buy from them.

[zilp]

Steve's rationale about RISC-V is also one I agree with. Its a nice processor architecture with a great future, but perhaps for FPGAs and HW designers and not in user-programmed/facing SoCs. The extensability and freedom of the ISA means it can make things less predictable for the end user (programmer).

But that's no different than ARM, is it? ARM also comes in many variants, and it also supports extensions, which are also used here and there ... but that doesn't seem to be a huge problem for its adoption either?

After all, there is a reason why manufacturers use RISC-V in the first place (and ARM, for that matter, and also MIPS, which might be relevant for this thread in particular) instead of some in-house design. I mean, there potentially are multiple reasons, but a big one certainly is precisely compatibility. In a way, the hard part isn't designing an ISA, it's building all the supporting (software-) infrastructure, such as high-quality compilers that support powerful languages with modern features and all that and that squeeze as much performance as possible out of the hardware ... and with ARM, MIPS, and RISC-V, you get those for free.

Adding gratuitous incompatibilities to a given implementation of RISC-V would therefore run counter to the reason why a manufacturer would choose RISC-V in the first place, as they suddenly would have to start maintaining a compiler fork for their incompatible implementation, as the upstream maintainers would be rather unlikely to be interested in patches for effectively broken implementations.

So, more likely would be backwards-compatible proprietary extensions that you as a developer can simply ignore if you don't need the particular benefits of that extension, and a basic segmentation based on application profile, such as versions with and without floating point support or hardware multiplication or whatever, which is actually part of the standard, so shouldn't be a huge problem for developers ... and both of those are what you also see with ARM.

[mikeselectricstuff]

I really like the Microchip factory programmed service option. Not sure how many other players have that service radily available for everyone?

I've not seen this from any other manufacturer, indeed I'm not aware of anyone else that sells their parts direct in low volumes.
Third-party programming services are IME way too expensive to be useful for lower-cost parts.
Digikey offers programming but only within the US, because you might be asking them to program export-controlled encryption (seriously, that's what they told me). No idea what the cost of this is.
There are other aspects that I think are unique to Microchip :

Same IDE/programming tools, and very similar peripherals  over the whole range from a 6-pin SOT23 PIC8 to a 200MHz PIC32. (It is actually possible to write code that works on 8,16 and 32 bit parts where the only change is a few config fuse settings.  )

Typically 3-4 package options for every part, often including DIP and large SOIC. Does anyone else do 32 bit, or USB Host in DIP?

Never obsoleting anything - very important for long-life industrial applications.

In most  parts, very flexible peripheral pin mapping - in many cases pretty much any pin to any peripheral.

Configurable logic cell, handy for when a peripheral doesn't quite do exactly what you want. I've used this to do things like generate complimentary UART signals to drive a local DMX fixture and generate WS2812 data in hardware by combining SPI and PWM peripherals.

[EEVblog]

I mean, you are effectively arguing that businesses shouldn't reduce prices because a sufficiently high price could be the quality that customers are choosing the product for

I'm not really arguing anything. I'm saying that I'm happy to accept Sanghi's reasoning, and that it's quite likely he has way more insight and spidey sense about this than us consumers.
I also don't see how the only difference with the paid version is slightly higher optimisation is such a big deal. Otherwise it's all free.
If the free tool was crippled in other ways then I might complain a bit more.

[zilp]

I'm not really arguing anything. I'm saying that I'm happy to accept Sanghi's reasoning, and that it's quite likely he has way more insight and spidey sense about this than us consumers.

Well, yeah, arguing in the broadest sense of "using an argument to justify a position" ...

I guess what I am wondering is this: Is your position in any way falsifiable? Like, is there anything that, if it were demonstrated to your satisfaction, would make your doubt his reasoning and/or his conclusion on anything regarding the company, apart from Microchip as a whole failing as a business?

I also don't see how the only difference with the paid version is slightly higher optimisation is such a big deal. Otherwise it's all free.
If the free tool was crippled in other ways then I might complain a bit more.

But the point is that that makes it even less sensible economically? I mean, I agree that it's probably not a huge deal for most customers ... but then, the less of a deal it is for the customers, the less incentive they have to buy licenses, so the less money they'll make from selling them, so ... why bother in the first place?

Like, if they charged 3k per user per month for the base compiler, say, and they could convince people to actually buy that in significant numbers, possibly because their chips are just so good that people are willing to pay the price to use them, then I would see how that maybe would be a significant contribution to the business success, even if some customers would understandably complain about the upfront cost ... but given the relatively minor limitations and the pricing, this seems like it's only going to annoy some (potential) customers without any significant revenue to show for it, which is precisely why it seems like such a weird business decision.

[barshatriplee]

This is the first time I have come to know his name. Thank you for sharing.

[EEVblog]

I'm not really arguing anything. I'm saying that I'm happy to accept Sanghi's reasoning, and that it's quite likely he has way more insight and spidey sense about this than us consumers.

Well, yeah, arguing in the broadest sense of "using an argument to justify a position" ...

I guess what I am wondering is this: Is your position in any way falsifiable? Like, is there anything that, if it were demonstrated to your satisfaction, would make your doubt his reasoning and/or his conclusion on anything regarding the company, apart from Microchip as a whole failing as a business?

I don't care.

[SiliconWizard]

I mean, you are effectively arguing that businesses shouldn't reduce prices because a sufficiently high price could be the quality that customers are choosing the product for

I'm not really arguing anything. I'm saying that I'm happy to accept Sanghi's reasoning, and that it's quite likely he has way more insight and spidey sense about this than us consumers.
I also don't see how the only difference with the paid version is slightly higher optimisation is such a big deal. Otherwise it's all free.
If the free tool was crippled in other ways then I might complain a bit more.

Not just that, but the source code is provided (XC16 and XC32). Granted they don't make it particularly easy neither to find the downloads, nor to build the compilers (I've done it before and it's a bit messy), but it's open. For XC8, as they bought the compiler, I don't know to what extent they could have open-sourced it anyway. Sure for XC16 and XC32, you may argue that they didn't have a choice due to GCC licensing.

For a number of people, the concern is not the cost of the tools per se (for commercial dev), but the possibility that said tools could become unavailable or unusable in some way in the future.
But again, the source code is available. Even if the compilers are not trivial to build, it's not impossible at all. So if/when the need is really there, a lot of people will just do that.

Now the issue is again more with XC8, and in that regard, I can understand why one could shy away from Microchip 8-bitters these days. (Interestingly, many only think of 8-bit PICs when thinking about Microchip, while they have a wide range of 16-bit and 32-bit MCUs.)

The only open-source compiler that has been half-maintained is SDCC, and AFAIK, while it works great for other targets, it's never been all that great for the 8-bit PICs.

One thing that has become really annoying to me is Microchip's stubbornness about using their own ICSP interfaces on most of their MCUs instead of a standard JTAG (or SWD) that would allow using standard JTAG/SWD adapters and tools. I think only their PIC32 series have a JTAG interface, but I'm not even sure that MPLAB supports any JTAG adapter. So you're basically stuck with their ICDx/PICkit stuff. But that may be part of their overall strategy, so.