Having shipped some quick wins like the CircuitPython bridge and pub-sub example applications, we’re shifting focus toward the longer-term accessibility goals for the year.
The main objective we’re aiming toward is this: Integrators should be able to implement Bristlemouth on other platforms cleanly without forking, choosing what parts to pull in from various lib/tools. This isn’t possible with the current monolithic design that depends on a specific microcontroller, RTOS, IP stack, and networking chip.
There’s a concept from design thinking called “flare and focus”. To design great products it can be helpful to decide at each phase which type of work you’re doing. “Flaring” means brainstorming, generating lots of ideas, and toning down your critical voice. “Focusing” means using critical thinking to prune down to the best ideas, and execute them rapidly without distraction. For more info on this concept, here’s a good article from the Stanford d.school.
Because the best software architecture is not clear to us right now, the Bristlemouth core dev team has decided to enter a Flare phase from now through August 23, the next 6 weeks.
The goal for the end of the Flare phase is to have a rough first draft of Bristlemouth firmware API docs written. Through the experiments of the next 6 weeks we hope to build consensus around a good API design.
I’ll be running casual weekly meetings during this phase focused on idea generation and writing down what we’ve learned. The first one will be Thursday, July 18, 10:45-11:30am PDT (San Francisco, UTC-7) = 17:45-18:30 UTC.
Anyone should feel free to join, even just out of curiosity. Feel free to come and go. It will be informal, and I want everyone to feel welcome. Video call link: https://meet.google.com/oof-hudt-ewb
We will also have a live discussion topic going here on the forum during the meeting, which can continue afterward to allow folks to participate asynchronously. It will also serve as a long-lived record of our process.