So very sad. Ben Fry is one of my heroes. He's done an amazing job with Processing, over a very long time. I can't think of any other open-source project with the same consistency of vision and quality of execution, plus the level of design and usability.
I read a lot of Ben's code while I was working on the IDE for Arduino. It was always extremely clear, robust, and well-commented. And occasionally hilarious. My favorite part was the prompt to take a walk that showed up when you had created a new sketch for each letter of the alphabet on a particular day (sketch names defaulted to something like 20231003a, 20231003b, etc). But there were also some good digs at the failings of Processing's various dependencies, like Java and Mac OS.
The world of computational design and open-source software is much better for having Ben Fry and Processing in it.
One thing that I think is lost in a lot of the comments here is that, to a large extent, privacy is experienced, not factual. That is, in many cases, the breach of privacy is the act of mentioning something that should be private, not whether or not the system (or the person) knows that thing. This is something we tend to intuitively understand in our human relationships, but one that somehow seems to be forgotten in the design of these systems (or, at least, the conversations about them). We need good ways to tell the Google Assistant that something is private (or for it to figure it out for itself) -- even if it still possesses the underlying data.
(There are, of course, situations in which the actual existence or not of specific data is what matters, but I think those are less relevant to the success of something like Google Assistant than the perception of privacy -- and that perception is important, regardless of the underlying data.)
There are use cases for things like Arduino (a microcontroller development board). We'd like to allow uploading to Arduino boards from an online IDE. We'd also like to allow for interaction between sensors and actuators on an Arduino board and websites (e.g. programs written in the Scratch visual programming language). Yes, we can do much of this by having the user install a local application that communicates via web sockets, but that has its own security implications and adds an additional step for the user.
For hand-soldering, it might be nice to include 1206 packages in addition to 0603 ones, although I realize that would make the list much longer.
Another good reference for this kind of thing is the Fab Lab inventory: http://fab.cba.mit.edu/about/fab/inv.html and it might be worth looking that over to see if there's anything that seems worth adding.
My former advisor, Leah Buechley, and other friends created this introduction to programming and electronics via e-textiles and the LilyPad Arduino: http://sewelectric.org/
As someone who's tried to get from San Francisco to Silicon Valley without a car, I'd love to see companies like Google advocating and supporting better public transportation as well as just providing a private solution.
I've tried to source the components using as few vendors as possible (currently DigiKey, SparkFun, and Arduino, plus ordering the PCB) but it's definitely more work than just buying a kit. I'm working on a better solution but it's probably a ways off.
The key point here is the difference between copyright and patents. If someone has a copyright on something, you can create an alternative (free) implementation of it. If they have a patent, you can't.
It apparently sounds pretty good, according to the people I've called. The reception seems pretty standard, although I don't actually display signal strength in the interface yet so I'm not totally sure.
As the person who made the phone, I think this is an interesting question.
Do we say that Apple doesn't build computers themselves because they buy the CPU from Intel? Or because they use Qualcomm transceivers (and lots of other off-the-shelf components) in their phones? On the other hand, we probably wouldn't say someone made a phone if they just put it into a different enclosure.
I can say that I spent a lot of time selecting all the components, putting together the schematic, routing the board, and writing the UI software. (All of that took a lot longer than laser-cutting the case.) Of course, it probably took a lot more work than that to create the GSM module. But that's also true of the microcontroller I'm using, the LCD, even the battery. Just about everything is built on top of the work of others (see the Toaster Project for an example of how hard it is to do otherwise).
Interestingly, this critique hasn't really come up from the people I've worked with to build the phone. I explain the function of the GSM module (and the rest of the components) but after putting it all together, people don't seem to think of the phone as just a box for the module -- in part, I'd argue, because they realize how many other things are in there too.
Again, though, there's a fundamental question here that I'm trying to explore with my research: what does it mean to do it for yourself?
I read a lot of Ben's code while I was working on the IDE for Arduino. It was always extremely clear, robust, and well-commented. And occasionally hilarious. My favorite part was the prompt to take a walk that showed up when you had created a new sketch for each letter of the alphabet on a particular day (sketch names defaulted to something like 20231003a, 20231003b, etc). But there were also some good digs at the failings of Processing's various dependencies, like Java and Mac OS.
The world of computational design and open-source software is much better for having Ben Fry and Processing in it.