Amazingly, our refrigerator doesn’t have an alarm for when you accidentally leave the door open.
In the last six months, we’ve left the refrigerator door open overnight three times. Because the light stays on when the door is open, another horrible design decision, the refrigerator thermometer hits 107°F by the time I notice it in the morning.
Using a Parallax Ping Ultrasonic distance sensor, the Arduino board detects its distance to the nearest object in front of it. If there’s nothing within 2 inches for greater than 5 seconds, then the Arduino board uses a piezo buzzer to make some noise. The system resets when an object is placed within 2 inches again.
On a whole, I was surprised how quickly I got up to speed on Arduino. My “Hello World” project, blinking a LED diode, took about 10 minutes to complete. This distance alarm only took 20 minutes beyond that, with a little bit of guidance on what hardware to use and access to tutorials on how to use it.
Up next: figuring out how to miniaturize the entire setup so I can put it in a small housing and deploy to production (aka use it in my home).
Although voting seems like an intuitive concept, there are a few major flaws that seem to be getting worse over time.
Voting is never truly representative
We assume voting is fair because it vaguely reflects some total population that we are trying to represent. It’s impossible to exactly pin down what “representative” means. (Similar demographics, interests, incomes, ideologies? All of the above?)
Voting is a competitive game
Voting is a zero-sum game, meaning that whomever wins does so at the expense of someone else. As a result, voting promotes competition, not cooperation. Players might coordinate as a means of gaining an edge (“if you vote for X this time, I’ll give you Y next time”), but ultimately, “winning” the vote means beating someone else.
So. We have our current system, and we’ve identified some emerging problems that we need to solve for. What does that look like?
Designing for cooperation, not competition
If you’re an avid board gamer, you’ve probably come across a cooperative game or two, like Pandemic or Forbidden Island. In a cooperative game, you work with, rather than compete against, your fellow players to achieve a shared outcome…
Open source is one of the most powerful, and underappreciated, ideas of our generation. Modern open source is about building and collaborating in public, not about the license. Most importantly, open source isn't conceptually limited to software development; it's most prevalent here because we have the correct tooling.
The other day, I was reading Tualatin City Council's work session materials for January 22nd (PDF warning). It's actually pretty interesting. Tualatin is considering a "Local Congestion Relief and Neighborhood Safety" bond measure, and the packet provides much of the background. But it's a PDF packet and I was only reading it because someone emailed it to me.
Which brings me to the three realizations I had:
Open source is Good™ because it increases collaboration. Increased collaboration means increased value creation. Ergo, civic engagement (and pretty much everything) would benefit from open source methodologies.
City data is really hard to come by. It needs to be manually collected and it's often out of date as soon as it's collected. Nowadays, any effort put into collection should result in a real-time, persistent data stream.
Cities should be learning from one another. Meaning, Tualatin must have a data profile similar to dozens of other cities in the US. If city A tries experiment B and it works, then we should use that knowledge as the basis of our evolution, infrastructure investments and otherwise.
Debt is the financial term, stolen for the sake of illustrating a concept.
Open source is debt because:
Open source software is not a sellable asset. It’s both priceless and devoid of monetary value. What counts is the business value it enables.
The liability, and effort required to service this liability, grows as: 1) the software gains users, and 2) those users become more dependent the software. Support is a variable accelerant to the liability (e.g. it can grow the liability at an exponential rate).
Maintainers hold the debt liability. Their ongoing labor is required to service the debt. Typically, maintainers can only escape the obligation by declaring bankruptcy: “it’s done” or “I’m done.”
This idea could be helpful framing for:
Businesses to understand their dependency on open source in CFO-friendly terms.
Communities to understand the debt burden carried by maintainers, and general health of the project.
Another, possibly more correct, way of thinking about this is: “every line of source code, open or closed, is a liability.” Businesses own 100% of their closed source liability. They like open source because they would rather own 0% the liability.
Some incomplete ideas I've been noodling on that I want to make public.
Ultimately, the goal is: the vast majority of WordPress users are excited and should be able to use Gutenberg on day one. Fundamentally, this breaks down into two objectives:
Make the end-user experience is so good that WordPress users actively want to switch to it. We need to continue user testing as we have been, and iterate based on real user feedback. We also need to market Gutenberg — communicate what users should expect and get them appropriately excited.
Mitigate WordPress plugin and theme incompatibilities, to minimize conflicts that would cause WordPress to fall back to the classic editor. Success is defined by the majority of WordPress users being able to use Gutenberg on day one. If too many can't use Gutenberg because of conflicts, then we've failed at launch.
I've been brainstorming some strategies for the latter, which really is two parts: identification and mitigation.
First, we need to identify the true extent of the problem: what plugins and themes are incompatible with Gutenberg, and in what ways are each incompatible? Some automated ways we can produce this data includes:
Manual/automated analysis of action and filters usage, etc.
Activate each in an isolated environment and take before/after screenshots of the editor screen.
But, I'm thinking good ol' fashioned crowd-sourcing might be most effective. What if WordPress users had an easy way to report whether a given plugin or theme was compatible with Gutenberg? We could collect this data in aggregate to get a good sense of what types of incompatibilities we should expect, and where we should focus our efforts.
Once we've identified the plugin and theme conflicts, we'll need to mitigate them. Doing so will require excellent documentation, so authors more easily understand the changes they'll need to make, and deputizing other developers to help with the outreach process.