A rant about lack of support on open source software, or anything else actually

[Siwastaja]

It is not about getting stupid, it's just that very young people (<30, maybe 35) tend to have some extra flexibility and energy to go through very long days, do many things at the same time, learn new things quickly, and still not burn themselves out. I'm close to 40 and already can see the best learning days are over. It doesn't mean I can't learn anymore at all, but it requires more time and concentration and is harder to do under stressful situation.

[Berni]

It is also obvious that the vast majority of people using libs like LWIP have little or no idea what they do internally. There is a POV on this and other forums that you should not get involved in say TCP/IP unless you can write your own stack, but that just isn't the real world.

I wouldn't say you need to know how actually write a TCPIP stack, but you should most definitely know how TCP/IP actually works under the hood. That way you better understand what the library actually needs from you to actually work. When something doesn't work you can use the knowledge of how TCP/IP works in order to track the problem down (even if you have no idea how the library actually implements that). This is why experience in the field is so important.

You can make the same comparison to a car mechanic. They don't actually need to know how the car works, as long as they know how to correctly remove a part and install a new part in there, then they know enough to do there job. In a lot of the cases they will actually make a good enough mechanic, most of the time they will be replacing brake pads, changing oil, replacing a light...etc But then every so often they will get a costumer with a weird issue where sometimes there front left wheel locks up and the computer is throwing weird error codes. The inexperiences mechanic will just start replacing things, the pads, the calipers, the ABS unit, the ABS computer...etc until the problem goes away. However the more experienced mechanic will know exactly how the braking system of a car works and will do some experiments on the car to locate the exact cause of the problem... that turns out to be a intermittent bad contact on the ABS computer, clean up that connector a bit, put it back together and problem fixed.

This is exactly what you get when you bite off too big of a software project as a beginner. It is all fine as long as you stay on the well documented path and everything works. But as soon as you hit any serious of a problem you are completely lost, trying  random things that don't seam to help at all, because you have no idea what is actually causing the problem.

Good software developers are hard to find and expensive. Code monkeys are easy to find but might end up being even more expensive in the long run as they never get the thing working.

[madires]

You can make the same comparison to a car mechanic. They don't actually need to know how the car works, as long as they know how to correctly remove a part and install a new part in there, then they know enough to do there job.

Then you end up with mechanics replacing a lot of expensive parts without fixing the actual problem (called 'sinnloses Teiletauschen' in German). TCP/IP is a complex beast and there are many levels between to have something running to some extend and a well working stack. Either you enjoy a steep learning curve or you need to hire someone. As abquke said, R&D is expensive.

[BradC]

Fair point. One would think somebody would have set up a forum with specific sections for specific OS software. Mailing lists are a 1980s/90s thing

Mailing lists are an 80's/90's thing because nobody (and I mean nobody) has come up with anything better. The other reason mailing lists persist is because they help weed out the twonks who can only use a web browser, therefore you tend to get a focused response from the people that are actually capable of and willing to assisting you. The other thing that works well with mailing lists is the ability to archive, sort, prioritize and delegate without having to worry if the person who's attention you are trying to get has logged in sometime in the last decade.

Case in point, I've been chasing down a _very_ obscure bug in the Linux thunderbolt driver when using hardware that pretty much nobody else uses in this manner. Because the developer is accessible by E-mail, I've had a fantastic response at times over months when convenient to both of us. That's never going to work in a web context.

With rare exception web sites/archives are shit, whereas anyone can keep archives of mailing lists and the more, the merrier.

[peter-h]

It is not about getting stupid, it's just that very young people (<30, maybe 35) tend to have some extra flexibility and energy to go through very long days, do many things at the same time, learn new things quickly, and still not burn themselves out. I'm close to 40 and already can see the best learning days are over. It doesn't mean I can't learn anymore at all, but it requires more time and concentration and is harder to do under stressful situation.

It depends on whether you work for someone else, or for yourself. If the former, then everybody I know has got sick of it (especially the server side programming treadmill) by 40. If the latter, then you can choose which niche you want to play in. I have always worked for myself, since I left univ. So I could always choose the challenges.

It's another discussion but working for yourself is probably the only reasonably accessible way to make decent money without killing yourself. It is generally impossible if working in a job.

The mistake I made, probably 15 years ago, was not going up the ETH learning curve then. That cost a lot of lost business. But even if I had, I would have just ended up doing then what I have been doing now. Just with different libs. Or paying somebody. Which CPU? Not sure; was the ARM32 32F4-like stuff around then? The curve is steep and will always be steep (unless you put in one of those ETH-serial modules which connect to a CPU UART). Well, you can't do everything... You have to choose a work-life balance, and I made that choice.

And it isn't just about developing a product. It is also about supporting it for years. You have to understand it sufficiently to be able to write the user manual.

I can work from 8am to 11pm, with some breaks for eating and mountain biking

I wouldn't say you need to know how actually write a TCPIP stack, but you should most definitely know how TCP/IP actually works under the hood. That way you better understand what the library actually needs from you to actually work. When something doesn't work you can use the knowledge of how TCP/IP works in order to track the problem down (even if you have no idea how the library actually implements that). This is why experience in the field is so important.

True to a degree (actually the bit you need to understand is the API principles, and this is where you get to poor LWIP documentation) but where will you learn this? Not by googling and reading hits on github Everybody had to learn somewhere.

Mailing lists are an 80's/90's thing because nobody (and I mean nobody) has come up with anything better. The other reason mailing lists persist is because they help weed out the twonks who can only use a web browser, therefore you tend to get a focused response from the people that are actually capable of and willing to assisting you. The other thing that works well with mailing lists is the ability to archive, sort, prioritize and delegate without having to worry if the person who's attention you are trying to get has logged in sometime in the last decade.

If www user == twonk, that reveals a lot

Anyway, a www forum, well organised, with an optional daily digest emailed, is the same thing as a mailing list, with an optional daily digest emailed. However the former allows discussion, which the latter doesn't (in any practical way).

[nctnico]

It is not about getting stupid, it's just that very young people (<30, maybe 35) tend to have some extra flexibility and energy to go through very long days, do many things at the same time, learn new things quickly, and still not burn themselves out. I'm close to 40 and already can see the best learning days are over. It doesn't mean I can't learn anymore at all, but it requires more time and concentration and is harder to do under stressful situation.

It sounds more like your brain got comfortable and never is challenged with new ideas. For one of my customers I work together on software with a guy who is well in his 80's and he is still sharp and able to deal with new things.

[nfmax]

The problems I find with ageing (65) are too many other commitments, and lack of mental stamina. I run out of brain well before the end of the day

[rstofer]

When you select hardware, somewhere in the decision tree there should be a reference to known working software.
If brand A has a rep for not documenting hardware to a level that allows the ordinary programmer to use the chip, choose another brand.

mbed LPC1768 is an example where I wanted to use Berkeley Sockets to transfer a bunch of commands from the LPC1768 to a LaserJet acting as a server.  The Sockets interface is well understood and C code is all over the place.  lwIP is essentially hardware independent and easy to use.  The code to tie it all together is in the mbed network library and likely written by NXP although I never looked.  Everything I needed was handed to me on a platter.

When you pick a chip, choose wisely!  Unless you can find functional code, ready to copy and paste, walk away!

[AndyBeez]

Getting older just means you appreciate the priorities. What maters versus all the crap that don't. In a coding sense, I've seen 22 year olds wet themselves because of a new javascript framework update on Github. OMG WTF Awesome! I used to see similar 'nerf' behaviour at MS developer conferences in the 90s - which could be a complete jizfest. Why? In 10 years time you'll be learning your CV is already 15 years out of date, so just learn to deal with the now and the necessary.

[DiTBho]

When you pick a chip, choose wisely!  Unless you can find functional code, ready to copy and paste, walk away!

That's what I think about two of the Olimex's Ethernet chips, but they are too much interesting (one is 32bit parallel bus), therefore I am willing to read the datasheets and implement all the low level from scratch, like I did, years ago, for the CS8900 when it was rare to find  something.

They same applies to Coldfire-v1 modules: mine have a built-in Ethernet module, but with ZERO C code, unless you pay.

[T3sl4co1l]

Don't read this as an endorsement necessarily, but merely a choice of venue:

You might have better luck at StackOverflow, or the CS or EE stacks.

Stack is, I guess, a bit notorious for being strict about questions that must be well-formed and researched, and poorly formed, or ignorant, questions quickly tend to get downvoted and closed.  But it's also open, in that, you can find an answer for almost anything, with the right keywords; and if not, likely you can ask that question and earn a few fake internet points along the way (yay..).  Worst thing maybe, it turns out a repeat of existing question that you just didn't find the keywords for; which still answers your question, though it may not feel very satisfying that way.  But hey, if it works, right?

So, do your best, collect all relevant info you can, search for most every permutation of keywords you can think of, and hopefully your issue is unique and new, and others benefit from it.  If you find your solution in the process -- rather anticlimactic, I know; and perhaps it would be nice to tell others that might be searching for x/y/z keywords but they actually need t/u/v to find it as you finally did; but if nothing else, you can always comment on, or add answer to, the post you found (minus new-account limitations if applicable).

If nothing else, think of it this way: it's a formal, gating, rubber-duck experience.  As you collect your facts and thoughts, you might catch something you didn't before.

It's an unusual environment.  Whereas the traditional forum suffers from abject anarchy (inbetween the totalitarian mods/admins, when applicable..), Stack suffers from abject democracy.  Even comments can be upvoted, and questions and answers can be up or down voted.  Moderators are elected.  Conversations are discouraged (but generally tolerated).  Facts and references do generally get upvoted, but answers ultimately rise by consensus, not truth.  (Which is by necessity anyway, say on the less hard-science Stacks, but generally accepted as how we do science, too, for better or worse...)  It means the reader is never free of their personal responsibility for critical thought.  But such is democracy: it can only work when every individual is responsible with what power they possess.

Which is as free software is, after all.  You get what you paid for, and that amount is $0.  Maybe it's helpful, maybe plugging it into your system causes it to crash and burn.  Who knows.  Actively malicious code isn't common, at least (and maybe is fairly obvious in its function, or obfuscation?), and usually the worst thing that happens is you waste weeks on end, trying to make something work, that, it seems more and more likely each passing day, never was intended to work in the first place.

The cost of purchase has been replaced with the cost of critically evaluating the resources: Is this fork better than that fork? Who has the most up-to-date codebase?  Do I even want the latest version?  Or do I want that similar other project instead?  And there might not be any good answer to these, other than, try them all yourself.  Which is one thing already, when you just have to download and install a package, build it, and play around in the app; it's another thing entirely when you have to integrate it into an embedded system, with variable amounts of porting required.  Let alone the difficulty in testing, as you may not have easy hooks, debug, IO, etc. to test the various features as you would on a PC.

There is no good/easy solution to this, of course; it's just stuff you have to do.


As for ranting, my last couple notable experiences include:

- Was given a laptop with Debian on it. Does have a graphical shell. But seems you can do basically nothing through it, besides open xterm.  Not even an install-programs or configure-system dialog.  Is this supposed to be encouraging me to like the ecosystem? (No, as it turns out; Debian is shite. But when there's no one around to tell you that...)  Eventually ended when I tried to get a specific version tool on the system, which didn't exist in the distro servers, so, just patch in some other server right? Suddenly some deep C runtime thing updated from the new server and fuckin' bricked.  (Laptop isn't useless, it has W10 on it too.  It's... I'm not going to say it's "fine", but it's usable.)

- The above was after such time I realized, no, updating is not actually a universal good.  ESPECIALLY in open ecosystems.  You want bugfixes?  Fuck you, have a new API too.  Sometimes fixes are backported to other versions, sure, but where does it say so?  There's no universal "oh yeah we got this, this sub-version is cool to use" message anywhere.  It's a free-for-all.  You get what you pay for.  Well, case in point, I've been using MiKTeX 2.9 for years -- technically decades now, I suppose -- I thought it might be worthwhile to update to latest.  (I forget if there were incompatible packages coming through that motivated that, or purely out of "man, this really is getting old, it must be crusty, surely the new version is improved".)  As it turns out, the latest (at the time, 21.1 I think it was -- wow, what an increase in version numbering, my old stuff must be TRASH!*) runs slower if anything, and is strictly incompatible with one of the most powerful packages I use (tabu isn't updated anymore, and is incompatible with LaTeX3, the major change).  Not to mention, upgrading was hair-pulling.  I think I ended up uninstalling it twice and fresh installing MiKTeX and it finally mostly worked (had to change some paths in TeXMaker).

*Chrome and Firefox incrementing on practically a monthly basis, should've clued me in: version numbers are as meaningless as anything else in this field.

And the replacement for tabu (tabularray) -- while nice by itself (with rare exceptions -- is very much incompatible.  ALL my old documents that used tabu, must be ported over to use the new system.  Because I thought updates were the responsible thing to get.  Fuck me.

- I integrated freemodbus last month.  Which is technically the first network stack I've implemented on something, albeit a lightweight one.  Neat.  (Well, maybe except for GPIB, but that's not really organized as a stack, that was a flat adapter really.)  It was a bit of work (a few days worth), just to familiarize myself with the structure, and ponder a bit about how to handle the porting (platform-dependent stuff goes in a couple files, of which the fork I started from had some #defines already between related platforms, not sure if I should follow that, or, who cares?*), but the stack itself Just Works(TM).  Well, I did find two bugs, one by inspection, one by test, both rather minor, and already on the tracker (but not implemented in current branch).

*No one cares. It's free software, remember!

That it works by callback functions, is kind of annoying, from an embedded standpoint.  It could be streamlined a lot.  C++ for example would be able to realize (I think?) that these pointers/structs/whatever are all static through the program, so can be optimized down to straight calls; but this is C.  But most of the code runs from main() anyway, and the baud and poll rate are both low enough that, who cares, it's hardly anything.  So, it's fine as it is.

- Or stuff like compilers, or related toolchain stuff.  The latest often isn't the greatest, differences between avr-gcc 4/5 for example have been mentioned before.  avr-libc is out of date for the latest generation parts.  MCP has their own version but last I checked it wasn't available publicly (I had to ask for updated headers).  When I started with AVR-DA, it was juuuust early enough that free tool support wasn't quite there (pyupdi / pymcuprog was functional, albeit slow).  Since March or so, AVRDude has integrated it, and things feel pretty normal.  Granted, every new wrinkle that adds and modifies my toolchain(s), means one more step removed from "standard" AVR Studio workflow, and who knows how compatible those are (if anyone should need to build/modify my code, that is, which so far hasn't been much).

- On the other hand, I've had nothing but success with Doom ports, for example.  GZDoom and friends are... they've only ever been drop and play.  No library fuckery (appropriate version SDL is included).  No configuration (at least anything that you can't find in menus, and rarely anything that's not in your existing config file).  No installer.  Dump it in your Doom folder and go.  It performs well*, it's incredibly rich with features (software/GL renderer, visual tweaks, postprocessing..), and, I don't think I've ever had it crash or anything, that I can't attribute to bad add-ons or my own fault.

*The worst performance I've seen, is extremely rich scenery, like Elementalism (which I highly recommend, by the way, if you're much into FPS at all, let alone Doom as such; it's very much a modern creation!).  And even then, the performance isn't much worse than others, despite the age of my computer (I think most struggle to render the richest scenes at 60 FPS; I got down to 15 FPS or so, which, sucks, but is still very much playable: controls/behavior are still real time, just the rendering is delayed).  Needless to say, these are terrifically embarrassing rates for the number of actual triangles being rendered, but... it's a force-fit, having to render all that through Doom's BSP trees plus whatever hackery makes for sector-over-sector in these WADs (reference sectors? portals? I don't know; several tricks actually I think).  More that it's doable at all, given the limitations imposed by the engine, and is still playable.

Anyway, I'm sure I can think of others, but that's a good enough cross section to paint the picture.

Or uh, perhaps too obviously, I'm using Chrome right now, or Firefox from time to time.  But Chrome in particular is very much a commercial product---it has literal employees working on it.  Such projects are highly exceptional in the FOSS ecosystem overall.  They're an example, sure, but very, very far from the rule.  So, not including in the above list for that reason.

Tim

[mikeselectricstuff]

The right tools: Why not use a Linux SBC board, where many things that you need are already done?

That in itself can be a collossal learning curve, and if/when something borks, you potentially need to dig through an awful lot of someone else's code. The flipside is that if it's a ready-made board,  even if only for prototyping, there are other identical boards out there and someone else may have found a solution to the issue you're seeing.

And it was never like this in the past, when chips were simpler. I developed literally hundreds of products over 40 years, all working alone. Just did it from data books. No internet.

The problem is the new functionality. It is so massively more complex.

This. Exactly.

It is not reasonable to expect free support from a manufacturer unless you are going to be buying significant numbers of parts, it just isn't worth their time - annoying but a reality these days.

Basically you either need to put in the time yourself, or pay someone who has already done so, either directly or by buying in modules/subsystems that are already proven. 

For example a few years ago I needed to implement a UDP client, and at the time knew pretty much zero about ethernet. Despite the processor I used having an ethernet MAC, I just used a Wiznet chip which handled it all & had it running in a couple of days.

 

[free_electron]

Manufacturers used to have applications engineers. Guys that were salted and pickled and knew their products.
The "development boards they hand out today is the simplest possible thing , accompanied by a bunch of software they did not write ,nor understand , and one simple demo that does a simple thing.
Ask anything outside that box (or inside the 3rd party stuff provided) and it's crickets...  you have the source , use it. we don't know. We gave you a demo that's it.

We are having our lunch eaten by the chinese. They will take anything, throw a massive amount of work against it (because they can afford it), ship it, wart's and all , and the company will disappear after they milked the fat rich westerners for money.
Open source is stupid. stupid in the sense :you are giving away the technology. technology that is valuable. unscrupulous people will use it without "giving back to the community."

Companies are evolving to become farmers with their clients being the milkcows. SaaS , HaaS , Cloud computing , pay to play, apps and their updates are the prime examples. pay a monthly subscription.
Want GPS in the car ? pay ! , heated seats ? pay ! watch tv ? pay (public broadcasting used to be free)

i was telling my wife that furniture is next. Want to sit on your chair to eat lunch? Pay. A big screw will come out the middle so you can't sit on it. pay per hour . if you forget the subscription the chair will literally screw you. Next toilets : they will weigh your morning core dump and charge you per gram , notifying the doctor and pharmacist what pill to send because the color and consistency is off. Al wirelessly toyour phone. The application will be called BlueStool (instead of bluetooth)

There are places where you have to pay , depending on the size of your roof, for the rainwater you collect.... i can't control it : it's falling out of the sky ! yeah, but you are using it : pay. you are stealing revenue from the water company and the farmers cause that wate ris supposed to go in the ground to feed the aquifers the farms drill their wells in.

[peter-h]

It is not reasonable to expect free support from a manufacturer unless you are going to be buying significant numbers of parts, it just isn't worth their time - annoying but a reality these days.

Disagree totally. ST is a 14BN € company. They can't afford 1 or 2 engineers to deal with questions?

[SiliconWizard]

It is not reasonable to expect free support from a manufacturer unless you are going to be buying significant numbers of parts, it just isn't worth their time - annoying but a reality these days.

Disagree totally. ST is a 14BN € company. They can't afford 1 or 2 engineers to deal with questions?

Given the number of their customers, 1 or 2 would be like pissing in the sea while making the life of those engineers miserable.

It's unfortunate, but the semiconductor industry - except maybe for the very niche parts - is a high-volume business. You just can't serve low-volume customers with the same amount of support and keep being profitable. It doesn't work.

One thing to keep in mind as well - and you may be well aware of this as a company - is that the more tech support you give to customers, and the more likely it is to backfire at some point.

[Siwastaja]

And those who buy 10-20 chips often require the most attention.

People contact the manufacturers with questions that could be answered by just reading the documentation carefully. 99% of the questions are like that, caused by laziness.

The problem is, there is no way for manufacturers to filter true questions out of this noise.

[SiliconWizard]

One support model that can work - but I'm sure many don't like it - is to offer paid-for support.

If you're a big customer, then support may become free.
If you're a small one, then you'd have to pay a fee. To make it fair, and filter out laziness while still offering true support for customers running into a silicon bug or ill-documented feature, then I suggest the fee could be reduced down to zero if support determines that the customer indeed found a real bug, for instance. There could also be some kind of reward system, so that customers who helped find a bug or improve a product in any way would get free support tokens, or something like that. Add to this an easy way of open "tickets" and buying support (instead of having to go through hoops with the sales dept for instance), and you could have a winner. Just a thought.

[nctnico]

It is not reasonable to expect free support from a manufacturer unless you are going to be buying significant numbers of parts, it just isn't worth their time - annoying but a reality these days.

Disagree totally. ST is a 14BN € company. They can't afford 1 or 2 engineers to deal with questions?

Given the number of their customers, 1 or 2 would be like pissing in the sea while making the life of those engineers miserable.

If I look at the support forums from NXP and NVidia, the number of support engineers is just that. 2 persons (maybe 3) that have some access to the software and hardware development team. In many cases their replies consist of pointing to documentation or existing threads but if you really have a new problem, the support people at NXP and NVidia are useful to get answers from.

So yes, 1 or 2 support engineers can make a lot of difference.

[peter-h]

is that the more tech support you give to customers, and the more likely it is to backfire at some point.

Why?

but I'm sure many don't like it - is to offer paid-for support.

Paying for support tickets has 2 issues a: it carries a perception of greed b) people wil expect a decent service level

And those who buy 10-20 chips often require the most attention.

They might buy 10000 later... I have used that volume of CPUs in my little business, in years past.

You just can't serve low-volume customers with the same amount of support and keep being profitable. It doesn't work.

That's not how it works. Social media makes participation very easy. The cost is very low. I have seen it done well, and I have seen it done badly The main thing is that the company needs to be properly behind it, and give the front man access to real people inside.

So yes, 1 or 2 support engineers can make a lot of difference.

Exactly.

[Berni]

They might buy 10000 later... I have used that volume of CPUs in my little business, in years past.

Yep at that point you will get much better support from them since you are a sizable costumer.

Problem is that for large chip manufacturers they have way too many people using the chips. To really answer any random person on the internet in a timely and high quality fashion would need a very large team of people that are actually knowledgeable with the products. They instead use the smart people in engineering.

For companies that have to provide support to the average joe (like a ISP) you will usually find a pyramid tier system on the phone. When calling technical support the first person you get on the line is usually some intern that only really knows to tell people to reboot there modem. When that is not the solution you get transferred up to a person who actually knows something, this is the guy that will send a tech if they identify a problem on your end. But if it is not a costumer side issue then you get your call promoted yet again up to the people who actually know how the ISPs network works and can solve the more serious problems. This way they can have the cheep intern students solve 90% of support calls by explaining to grandma how to reboot a modem over a lengthy 30 minute phone call.

But when it comes to support for very technical things like chips even the first tier has to know a lot to actually be of any use. While you indeed won't get grandma calling in to ask why her I2C peripheral is locking up when used by DMA, you will certainly get a lot of beginner engineers flooding in with problems that just stem from them not reading the datasheet correctly.To make things worse these tickets can waste a lot of time too due to the poor debugging skills of the client. They will often provide a short vague description of the problem, never list out what they already tried to do to solve it, then followed by them copy pasting a huge wall of code that contains all sorts of other crap in it (rather than a short concise test case for reproducing the problem) while the problem might even be in some other source file that they didn't copy paste.

Once you get to costumers that have already bought thousands of chips this makes a good filter that the costumer actually knows what they are doing. That way you support costumers that actually make you a profit while making sure you don't get nearly as many silly time wasting support tickets.

Is it fair that companies do this? Not really no. But they are a business after all, being nice to strangers on the internet doesn't directly put green numbers on there balance sheet.

However you will find companies put some effort into providing educational material towards academics. That way they can teach people how to use there MCUs instead.

[peter-h]

Yep at that point you will get much better support from them since you are a sizable costumer.

Actually, you won't (IME).

[westfw]

Manufacturers used to have applications engineers. Guys that were salted and pickled and knew their products.

They'd talk to you if you were a big enough company, or if you happened to spark their interest for some reason and they weren't busy.

But in those days, your nominal 2-person company probably couldn't even buy chips.  :-(
I worked for a company that went from so small that vendors wouldn't want to talk to us, to so big that they'd happily lie to us about how wonderful their new chip was going to be (in hopes of being selected.)  Interesting times!

It helps SO much to have:

• Several engineers with complementary knowledge.  And visions.
• A community of people with similar interests.  There is a reason that not-very-great products like 8052-Basic, Parallax BASIC Stamp, and Arduino, have had "great success."  A lot of that is a hierarchy of people ranging from clueless beginners asking "can I do xxx?", and somewhat less clueless folks thinking about the answers, to near-experts figuring out how to MAKE it work.  Sometimes this is forums, sometimes mailing lists, sometimes ... something else.
• Clue-full customers.   People who will do more than complain that "it doesn't work."

I ... don't know how to explain the general awfulness of vendor forums.  It's like ... you need to attract a certain percentage of beginners that ask the stupid questions that in fact lots of people were wondering about.  And you have to put up with them, and that the same stupid questions will get asked over and over again.   On a good forum (here, avrfreaks, PICList, Arduino forums, maybe the RPi Pico forums) you eventually build up a middle tier of people who aren't the vendor, who are nevertheless capable and willing to answer those questions.  (EAGLE used to do this - they had newgroups, and most of the "new free-version-user questions" got answered by other customers, rather than by the EAGLE people.)   I think too many vendor forums try to have a "customers ask questions, and one of our people will answer them; maybe" model, and it doesn't scale.

[peter-h]

The reality has always been, since the earliest days of the internet (Compuserve, Usenet, etc) that manufacturers have been scared of social media.

And for good reason, with sites like Trustpilot often slagging them off.

I've been involved with running forum(s) and this has often puzzled me. They just have an institutional paranoia about getting involved. They don't seem to get that if they did it right, they would get a lot of business. On the one I run now, we have a rule that commercial posters can advertise their products if they participate generally in the forum, but 99% of the time I get every possible variation of advertising without contributing anything! OK; for chip support this would not be a good model because one really wants full time mfg presence, just answering questions and such. I absolutely do not buy that a 14BN company cannot afford this. They probably have a whole team monitoring social media and managing their SM profile, to optimise google hits (SEO is huge business now; even I pay £250/month) and to control negative stuff. 1 or 2 people did it well and one guy (just him working alone) was getting 50k/year of business from his forum postings!

The ST forum is a total joke, even when you allow for most questions being stupid. But even carefully formed specific questions do not normally get answers. There is no mfg presence.

Open source support is a separate thing and obviously more difficult because nobody is making money. Well, they might be. Look at the Magento online shop. Free, OS, and there are 10000 "Magento consultants" who make money out of setting it up for you and maintaining it. My huge mistake was to get the "Monday guy" to implement ours; it took him a year or two of Mondays. I should have just paid 10-20k to somebody. Now I pay per hour to a guy who set it up on a fresh virtual server (it used to run in-house - another crazy idea) and his costs work out at £100/month; often zero. A lot of online shops are going to Shopify and again an army of "consultants" exists around that (I wouldn't touch a "cloud based" shop, especially one hosted on the impossible to contact AWS, with a bargepole). Hence I am surprised that there isn't anybody making money out of integrating LWIP, FreeRTOS, MbedTLS, etc. Right now I would pay someone ~1k for some consultancy on these (go over the implementation, latest patches, etc) even though the current system runs solidly. But only experts can make money on a fixed price job; everybody else has to charge hourly and then the customer tends to get ripped off. And of course such people would participate on specific forums for these, if they existed, which they don't, because the existing ones are all dead.

[T3sl4co1l]

A community of people with similar interests.  There is a reason that not-very-great products like 8052-Basic, Parallax BASIC Stamp, and Arduino, have had "great success."

This is an interesting point, because it generalizes.

What makes cars great*?
What makes the American healthcare system great*? (or any other hot button political issue)
What makes sports great*?
In fact, applied theory right here for 'ya: what would be, very much not-great, about allowing unlimited doping in Olympic sports?

Anything truly "great", in a systemic sense, returns value at every level.  Cars get people around faster and cheaper than horses.  Cars sell gas.  Cars sell maintenance.  Cars sell.  Cars make roads.  They return value at every level, from the everyday person to the highest levels of auto and oil execs, and more.

*To be clear: whether that's "great" in a moral sense, or for a maximal number of people, etc.: that is, sadly, beside the point.  American healthcare illustrating this in perhaps sharpest relief among the examples here.  Systemic, as in, the whole thing simultaneously, accounting for all forces acting for and against the thing.  On the whole, it seems we're stuck with these, for better or for worse, at least before a great many other things change first -- that's why they stay entrenched, they're part of a big network of interdependencies.

The applied case, then: doping top-level athletes implies doping mid-level athletes.  And so on.  Legitimizing use at the highest level, at the very least encourages others to do it, and to simply get better at avoiding tests.  We could excuse the bodily self-abuse of top athletes, in search of ultimate human limits, sure; but it gets much harder to do, when you realize how much training goes into that, between however many people -- there must be a ready supply of competitors to choose from, that only the best are selected from.  And a supply of up-and-comers vying for those positions, and so on.  So it affects everyone from the lowest to the highest, and is altogether...just not a great idea.

Perhaps this is a more obvious example than the others, perhaps you've pondered this before; the point is to ponder just a bit further: it generalizes -- the pyramid structure is very much relevant to the present topic.

Arduino for example, you can dismiss it if you like, as some unprofessional hack-job -- but the fact remains, its presence affects professionals.  I've seen boards themselves on desks several times, and even if you aren't using the boards and libraries, you may benefit from all the code implementing or supporting it (like device drivers).  Personally, I've used, at least a display driver, which involved porting an Adafruit Arduino module to C (they're normally C++).

Or the Basic Stamp things.  They've been around for AGES.  I have Electronics Nows from the 90s (and, probably including that magazine's predecessor too, in the late 80s or whenever the thing was introduced?) plastered with their ads.  Be cynical if you like, about BASIC, or that product's capabilities, but clearly they weren't a losing proposition!  BASIC itself has served as an introductory programming language to millions (maybe billions even..?), problematic though it is with respect to more practical, or pure, computer science, as the case may be.  I... doubt many were buying Stamps in much quantity, but viewing them as a stepping stone to the wider embedded ecosystem(s) -- that which Arduino is bigger at today -- absolutely!

And Arduino, being as open and accessible as it is, has been ported to dozens of platforms.  You can have the full power (well, minus library cruft) of a Cortex M4+ (or more? I don't even know what the most powerful MCU is, supporting Arduino*..), or as little as an AVR.

*Well, probably something like rPi, though that'd be going through OS calls to set up peripherals, GPIOs, etc., not library drivers.  Hm, maybe it's not actually implemented on that, actually...

So, as for applying this to present circumstances -- IC manufacturers -- it doesn't matter, systemically, where that lead-in occurs.  It could involve free samples, or at least at-cost dev boards (as it has briefly in the past, like the uh, some of the LaunchPads were seriously marked down for a while, weren't they? Those were the days, huh..), and that's their economic "in"; and anywhere from unofficial/3rd party forums, to an army of engineers supporting their official forum (or these days, perhaps a Stack).  Heck, Arduino has proven you don't even need those first two -- just as long as the chip gets in there.  rPi is another example, come to think of it (with a more direct connection instead).

And then it leads all the way up to the highest levels, where seasoned engineers are choosing products based on familiarity and availability; familiarity which was won years ago in the lead-in phase, when they were at the bottom of the pyramid, and picked up whatever dev kits they did.

Well, with tight supplies as we have today, manufacturers are forced to prioritize.  They're going to drop the numerous, less profitable, little customers; eventually, that will cost them their positioning at the lowest tier of the pyramid, or indeed destabilize it (since most everyone is coming up short here).  But it will take much time for that to bite them.

Hm, I wonder what kind of time constant(s) relate to that, anyway?  Probably very distributed, since you've got everything from older people and slow learners (for whatever reasons; maybe they just can't spare the time to learn a new toolchain, that counts, too); to fast-learning geniuses, and current students.  The students that are slow-learning, or that turn into old people set in their ways, would seem to be the first to miss out on, well, whatever product lines are short in supply right now.  The fast learners, or the broadly experienced, won't take long to change between product lines / toolchains, or are already familiar with enough to get by.

Which is to paint a more nuanced picture: it's not just one pyramid, but a bunch of them clustered together: broad roots, with many peaks.  More like mountains, with the various PIC and AVR foothills, the ARM and x86 and etc. mountain ranges... A nimble engineer can scale whatever mountain they need to, while others might spend their whole lives climbing up, sometimes falling down, never quite reaching the peak.  (Which is... about as far as the "mountain" analogy need be stretched.  Not to imply, you know, the usual place that goes: the triumph of conquering that peak...  This is work, it's fine to spend, you know, your whole career maybe, somewhere up or down the slopes.  There isn't really a peak here, it's all slopes...)

Would also seem like -- if you can get your product out at all -- now would be a great time to flood those bottom tiers with products.  This could be a great opportunity for RISC-V, say?  Since there are, as yet, maybe not so many production applications for them (I would guess..?!), maybe they could raise production and gain new adopters.  Is there Arduino on any yet?  SBCs to rival the rPi's?

Tim

[SiliconWizard]

The reality has always been, since the earliest days of the internet (Compuserve, Usenet, etc) that manufacturers have been scared of social media.

And for good reason, with sites like Trustpilot often slagging them off.

For good reason indeed. Typical social media for product support? Are you serious?
It's just a rabbit hole that can destroy your company in no time flat while bringing a lot of noise and very limited benefit for customers.