https://www.mistachkin.com/joe/ has been talking about setting up a Tcl Foundation and to use that to try to corral corporate donations toward further development. I think it’s a good idea and I’m trying to help. I’d recommend contacting Joe if you’d like to help.
We’re using tcl’s Androwish build, to write tablet apps for Android to control our espresso machine, and the app runs nicely on Mac/win/linux “for free” and also makes app development more pleasant.
Distribution of an app with source easily modified (no build step) encourages tinkering.
Androwish also has a cool mp4 casting mode which replaces the screen rendering, that lets you use your app inside a web browser. https://www.youtube.com/watch?v=2GBmB6JSDnQ
There are lots of people who have "Arduinoed" their coffee machines, especially the Rancilio Silvia, which is an ugly-but-good-value machine, which can be PIDed and hotwired. That's a good place to start.
The problem is that your mental model of how a boiler based espresso machine works is not how they are actually wired.
Here is how they actually work: 9 bar of pressure are generated between the pump and a flow constrictor which is placed before the boiler, pumping cold water into the boiler. This cold water then displaces the water in the boiler, which then gets pushed to the espresso.
Thus, the final pressure depends on the compressibility of the steam (or airspace) in the boiler. In practice, you get about half a bar less at the espresso than the pump got behind the boiler. But, the real numbers depends on lots of factors, many of which are invisible.
Ironically, because Tcl was made to run GUIs on very limited hardware (old Unix machines, 30 years ago) it runs really nicely on slow Android tablets.
Its focus on asynchronous programming, rather than relying on threads, really helps, as does the small memory footprint (105mb of RAM used for my app).
Java-based apps on the same tablet that I supply with the espresso machine run at a crawl, whereas my Tcl app feels normal.
This comment from one of the original consulting engineers is really interesting:
"Bio-Med Engineer Langhorne PA 13 hours ago
I worked in an engineering design consultancy that was contracted early on to help productize the ZPM design, and as such am intimately familiar with their initial concepts. In my opinion, the founders were initially earnest and dedicated but also naive and lacking in engineering judgement. They confused the ability to raise money with the ability to make sound engineering and technical decisions. Falling in love with one's ideas is a trap into which many inventors fall, and ZPM fell hard.
Additionally, I believe that ZPM received a lot of questionable advice from people who did not have their best interests at heart, and were swayed by strong personalities.
But the early backers - particularly the engineers - should have had the sense to realize that open-source firmware that is intended to control a consumer product that delivers scalding hot water is a fundamentally BAD idea, and that using a PID loop to manage the process is totally unnecessary.
What this article highlights is that Mr. Polyakov's talent is in raising money and expectations. It is unfortunate that neither his ethics, nor his engineering abilities can match those talents."
1) sometimes you come up with an idea that would make money at a certain scale (in my case, lots of shoutcast radio stations of Magnatune's music) but you can't do it because you don't have the money
2) I have to put a lot more time into making the software I write efficient and scalable, because I can't afford to buy lots of machines when the site grows. So, for instance, I tend to avoid doing a lot of SQL queries, which might be handy, because scaling that requires lots of SQL server machines.
3) In the old days (10 years ago, when I self-funded Lyris, which eventually became a success) a big problem I had was getting licenses to technology (C++ libraries, database servers) but these days open source replaces all that.
4) doing without employees. That's both a benefit in the near-term, as I have to learn how to do everything lean and well, but a disadvantage if there are rote tasks to do now as we scale. With BookMooch, I've managed to get volunteers to do those rote tasks, but with Magnatune, I got 3 not-very-well-paid part timers.