First Arduino project: distance alarm

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.

At yesterday’s inaugural PDX Raspberry Pi and Arduino meetup, I prototyped my solution to the problem: an alarm for accidentally leaving the refrigerator door open.

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).

Nothing is sacred

What’s wrong with voting?

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…

Nadia Eghbal – The problem with voting

Good first Gutenberg issues

Want to submit your first pull request to Gutenberg? Here are a few good first issues to get your feet wet:

Read through the contributing guide for details on how to get started. Feel free to ask questions on the specific issue, or join us in the #core-editor channel with any questions you might have.

RFC #17: Experiments and the Economics of Open Source

RFC #17: Experiments and the Economics of Open Source. I joined Nadia and Mikeal to discuss my work on WP-CLI, the economics, origins, staying productive as a maintainer, fund raising, and the state of WP-CLI "today" (aka last May when this was recorded).

Update: I forgot I said this: "[The GPL] is used often as a blunt instrument for enforcing certain economic dynamics around everyone's businesses." Pretty good!

Open source is debt

An idea I’d like to throw in the wild.

Open source is software businesses use to shorten time to market and accelerate their product. Some businesses build and collaborate in public because it’s a leverage strategy to get more from less. Most businesses maximize their use of open source software because they get it for “free”.

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.

Landing Gutenberg in WordPress 5.0

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:

  1. 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.
  2. 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.