Wakelocks and the embedded problem

The level of interaction by embedded developers can be roughly modeled by Brownian motion. Sometimes it is there, sometimes it isn't. For example, when working on the FOLK kernel patch set of obscure drivers, I encountered drivers for embedded hardware that would be there one week and vanish the next.

(I had a devil of a time trying to find VME or Fieldbus drivers that would sit still. The drivers would appear without warning - the companies rarely advertised them - and then vanished without warning.)

Sometimes, I would get all kinds of odd reactions to questions. The COMEDI developers were dead set against merging their code with the baseline, although I could never get them to give me a reason that made sense. I could never get much of a coherent answer from RTAI, either. I'm sure both groups had excellent reasons, and mean no offense to either, but I would have preferred to know what that reason was.

The Transputer drivers never made it into the mainstream, either, and I only discovered them on a series of barely-recognized FTP sites that didn't appear on most search engines. True, not many people used Transputers by the time the patch came out, but then not many people used the CBM64 when drivers for Commodore peripherals started circulating. There was zero documentation for the Transputer drivers, including any indication of who wrote them, and they'd clearly been abandoned a long time by the time I found them.

One of the reasons I developed FOLK was to stop this kind of nonsense from happening - people would have a better idea of what was out there, whether the developers liked it or not. (I got into a few tangles with GRSecurity over that. I can understand their reasoning of wanting to make sure security code hasn't been tampered with, but they have no control over what someone installing it does and they're now near-death from lack of exposure. They wouldn't depend as much on a single revenue stream if their work was better-known, better-circulated and better-understood. I can understand their position, but I can still resent the fact that Linux will be a poorer place when GRSecurity goes the way of the Dodo.)

I found many, many other embedded projects out there, and expect to find many many more such projects should I ever go looking again. These projects don't suffer from a lack of releases, a lack of open-sourceness or a lack of highly imaginative solutions. What they lack is an existence within the visible spectrum. What you don't see, you can't use. Sure, there are some "secret" projects out there, but if the published projects were getting some eyeballs, there'd be less need for "secret" APIs (as the problems with the mainstream APIs would be fixed or replacements would already be incorporated).

Sure, if more of these projects got discussed and more got included into the mainstream, it wouldn't fix all the problems in the world, or even in the embedded world. What it would do is reduce the number of opportunities for problems and misunderstandings to develop. Isn't that in the interests of both embedded and non-embedded developers?

I can even understand embedded (and non-embedded) developers being wary of the extra overheads involved in collecting together the various bits of work, documenting meaningfully the APIs and other such non-fundamental work that needs to get done. I'd even be willing to do some of this, if there was some chance it would make a difference.