Other writing: November 2019

What have I been writing when I haven’t been writing here?

Stuff I wrote

REd Hat/Fedora

Stuff I curated

Red hat/Fedora

Book review: People Powered

Jono Bacon knows something about communities. He wrote the book on it, in fact. And now he has written another book. People Powered is a guide for how companies can create and curate communities.

I often see companies try to start what they call “communities”. In reality, they are ways for the company to get free labor that provide no real benefit to the the participants. But it doesn’t have to be that way. A community that doesn’t benefit the sponsoring company is not likely to continue receiving sponsorship. But if there’s no benefit to the community members, the community will not thrive. Only when everyone involved gets value from the community will the community be vibrant.

A community mission is different than your business vision, but tightly wound around it.

All too often, books like this prescribe the One True Way™. Bacon does not do that. He fills the book with many things the reader should do, but he also makes it clear that there are many right ways to run a community, just as there are many wrong ways.

People Powered is a starting point, not an answer. As I was reading it, I thought “this is a good set of recipes”. Further on, Bacon used the same metaphor. Curse you, Jono! But it’s an apt metaphor. The book presents advice and knowledge based on Bacon’s 20 years of community management. But each community has specific needs, so the reader is encouraged to selectively apply the most relevant parts. And in the tradition of open source, plans should be iterative and evolve to meet the changing needs of communities. Like any good cook, the recipe provides a starting point; the cook makes adjustments to taste.

If I could sum up People Powered in two words, I would pick “be intentional.” Given two more words, I’d add “be selective.” People are often tempted to do all the things, to be all things to all people. And while that may be in the future of a community, getting started requires a more specific focus on what will (and more importantly, what won’t) be done.

People Powered is full of practical advice (including a lot of calls-to-action to find resources on jonobacon.com). But it also contains more philosophical views. Bacon is not a psychologist, but he has made a study of psychology and sociology over the years. This informs the theoretical explanations behind his practical steps. It also guides the conceptual models for communities that he lays out over the course of the book. And to prove that it’s a Jono Bacon book, it includes a few references to behavioral economics and several to Iron Maiden.

I really enjoyed this book. Some of it was obvious to me, given my community leadership experience (admittedly, I’m not the target audience), but I still got a lot of value from it. Chapter 9 (Cyberspace and Meatspace: Better Together) particularly spoke to me in light of some conversations I’ve had at work recently. People Powered is an excellent book for anyone who is currently leading or planning to lead a community as part of a corporate effort.

People Powered (affiliate link) is published by HarperCollins Leadership and was released yesterday.

Disclosures: 1. I received a pre-release digital review copy of People Powered. I received no other consideration for this post (unless you purchased it from the affiliate link above). 2. Jono Bacon is a personal friend, but I would tell him if his book was awful.

Other writing: October 2019

Stuff I wrote

Red Hat/Fedora

Stuff I curated

Red Hat/Fedora

New to Fedora: z

Earlier this month, I attended Chris Waldon’s session “Terminal Velocity: Work faster in your shell” at All Things Open. He covered several interesting tools, one of which is a project called z. z is a smarter version of the cd command. It keeps track of what directories you change to and uses a combination of the frequency and recency (“frecency”) to make an educated guess about where you wanted to go.

I find this really appealing because I often forget where in the file system I put a directory. And z is written as a shell script, so it’s easy to package and use.

z is now packaged and submitted to rawhide, with updates pending for F31 and F30.

Other writing: September 2019

What have I been writing when I haven’t been writing here?

Stuff I wrote

Red Hat/Fedora

Stuff I curated

Red HaT/Fedora

Sporting events should let meteorologists make weather decisions

Sporting events — particularly in the spring and summer when they’re generally done outdoors — present a hazard to participants and spectators alike. Thunderstorms can send a bolt of lightning in an instant, which can prove lethal. Part of the danger is that lightning can strike miles away from the storm, which means people who think they aren’t at risk might be very much at risk.

Many leagues and venues have adopted a largely sensible lighting policy. If lightning strikes within a certain radius, the activity is suspended and everyone is sent to shelter. After some amount of time without a strike (often 30 minutes), the activity resumes. This is, as a general concept, good advice.

Of course, it’s not quite as simple as “if you can see it, flee it. If you can hear it, clear it.” That’s the advice given to the public because it’s simple and easy to remember. But it doesn’t always capture the full story.

To give an example, this summer my local baseball team was playing a game as thunderstorms approached the area. A lightning strike occurred within the 10 mile radius defined by the Prospect League (as an aside, I appreciate the fact that they increased it from the 5 miles it used to be). The umpires suspended play late in the game (it was the 8th inning if I recall).

The trouble with this is that the storm was traveling perpendicular to the stadium. The strike that triggered the delay was well away from the storm and just inside the 10 mile radius. Essentially, it was as close as lightning would come. In this case, continuing play would be a safe decision. And it would have meant pitchers could stay warm and the crowd would have stuck around.

When it comes to weather safety, I’d always prefer overcaution to undercaution. But weather is complex, and the simple rules don’t always fit the situation. Sporting events should always leave weather decisions to meteorologists. High-profile near-misses have raised awareness, but it’s still not universal.

Decentralization is more appealing in theory than in reality

One of the appeals of open standards is that they allow market forces to work. Consumers can choose the tool or service that best meets their specific needs and if someone is a bad actor, the consumer can flee. Centralized proprietary services, in contrast, tie you to a specific provider. Consumers have no choice if they want/need to use the service.

It’s not as great as it sounds

This is true in theory, but reality is more complicated. Centralization allows for lower friction. Counterintuitively, centralization can allow for greater advancement. As Moxie Marlinspike wrote in a Whisper Labs blog post, open standards got the Internet “to the late 90s.” Decentralization is (in part) why email isn’t end-to-end encrypted by default. Centralization is (again, in part) why Slack has largely supplanted IRC and XMPP.

Particularly for services with a directory component (social networks for sure, but also tools like GitHub), centralization makes a lot of sense. It lowers the friction of finding those you care about. It also makes moderation easier.

Of course, those benefits can also be disadvantages. Easier moderation also means easier censorship. But not everyone is capable of or willing to run their own infrastructure. Or to find the “right” service among twenty nearly-identical offerings. The free market requires an informed consumer, and most consumers lack the knowledge necessary to make an informed choice.

Decentralization in open source

Centralized services versus federated (or isolated) services is a common discussion topic in open source. Jason Baker recently wrote a comment on a blog post that read in part:

I use Slack and GitHub and Google * and many other services because they’re simply easier – both for me, and for (most) of the people I’m collaborating with. The cost of being easier for most people I collaborate with is that I’m also probably excluding someone. Is that okay? I’m not sure. I go back and forth on that question a lot. In general, though, I try to be flexible to accommodate the people I’m actually working with, as opposed to solving the hypothetical/academic/moral question.

Centralization to some degree is inevitable. Whether build on open standards or not, most projects would rather work on their project than run their infrastructure. And GitHub (like Sourceforge before it), has enabled many small projects to flourish because they don’t need to spend time on infrastructure. Imagine if every project needed to run it’s own issue tracker, code repository, etc. The barrier to entry would be too high.

Striking a balance

GitHub provides an instructive example. It uses an open, decentralized technology (git) and layers centralized services on top. Users can get the best of both worlds in this sense. Open purists may not find this acceptable, but I think a pragmatic view is more appropriate. If allowing some proprietary services enables a larger and more robust open software ecosystem, isn’t that worthwhile?

The blurring lines of ownership

There was a time when you owned your car. Once you drove it off the lot, you could do whatever you wanted with it (subject to the laws of your local jurisdiction and the laws of physics). The manufacturer had no say in the matter — indeed they had know way of even knowing what you did. But this is beginning to change.

As hurricane Dorian approached the US coast, Tesla unlocked extra range on cars in the evacuation area. That’s right: Tesla 1. has the ability to change your car’s settings remotely and 2. is selling cars that intentionally reduce the range below maximum.

Let’s take a look at the second part first. Tesla, in order to offer a lower entry price, withholds some battery range by software configuration. You can pay them to get the full range. I understand they do this because it’s cheaper for them to have a single battery. But it feels scummy to me. Tesla’s costs are the same whether you buy the short-range version or the long-range version. So unless you pay them extra, you’re forced to drive around with extra weight. It’s like if Honda required me to keep two gallons of fuel in my gas tank that I could never use.

Tesla fans will defend this, and I understand their arguments. But it strikes me as a very uncomfortable middle ground between me owning the car and Tesla owning the car.

Tesla also, as I mentioned, has the ability to change this setting remotely. What else can they change? Presumably just about anything. I got to ride around in my friend’s Tesla earlier this year and you can do a lot from the app. Lock/unlock the doors, turn on the air conditioning, turn on the seat warmers. Unless the app is down., of course. (In Tesla’s defense, owners really should have a physical key of some kind with them because computers are the worst.)

None of this is me picking on Tesla, they just happen to be a convenient example and perhaps the furthest along the evolutionary line. At some point in the future, I suspect that individual ownership of automobiles will decrease dramatically. But we are not there yet. But we’re also no longer in a model where individuals fully own their cars. As cars get “smarter” the amount that the nominal owner actually owns them will decrease. Eventually we’ll cross a tipping point.

In the meantime, you have to decide how much you trust you car’s manufacturer. How smart do you want your car to be? Google, Amazon, Facebook, and the tech industry at large have shown little respect for the privacy rights of users. Does Tesla? If it does now, will it in the future? If Ford buys Tesla tomorrow, will they shut the servers down and suddenly your car is much less than it was.

This isn’t limited to cars, either. If your smart thermostat’s manufacturer shuts off the servers tomorrow, will your heat still turn on? If your abusive ex works at the manufacturer, can they access your data? Can they change the settings on your thermostat? Abusers are already putting connected devices to nefarious use.

None of this technology is bad per se, but we are woefully ill-equipped to handle it at this point. Existing laws and regulations were written largely for a different time. As a society, we have not yet come to define what reasonable boundaries are. The nature of ownership is changing. We need to change our concepts of ownership to keep up.

Book review: Ruined by Design

We’re fucked. That’s not a phrase you’d expect to see in a book on tech ethics. But it’s a major theme of Mike Monteiro’s Ruined by Design (affiliate link). You might think an ethics book would take a detached, academic approach. Monteiro has no time for that. He is passionate and opinionated throughout a practitioner disturbed by the state and trajectory of his trade.

Many people have found themselves being more political in the last few years. I should say being intentionally political, because the act of design as Monteiro reminds us is inherently political. For too long, he argues, designers have served the needs of their managers instead of advocating for the needs and interests of their users. That is how we’ve ended up with the garbage fire that is the modern tech industry.

Monteiro argues that designers have a moral obligation to do more than “push pixels”. Designers must design, and do so in such a way that treats the users ethically. This means being an active part of the decision-making process from the beginning, not just implementing someone else’s decision.

Ethical design faces some structural headwinds. Most significant of these is a capital environment that values rapid growth above all else. This both encourages decisions that grow engagement but not healthy interaction and also leads companies to grow so fast that design expertise is passed over or diluted. And there’s no such thing as an ethical offset, Monteiro says. Palantir is his go-to example of a company whose very essence is so unethical that nothing an employee does in their off hours can make up for what they do at the office.

So is it hopeless? Monteiro doesn’t think so. Designers, he hopes, mostly want to act ethically. They’ve just never had any training or mentorship that brings ethics to the fore. Designers must first be aware of the bigger ethical picture before they can start acting with intent. The rising public awareness of how tech companies abuse their users will help.

Monteiro views regulation of design as an inevitable consequence of the industry’s inability to self-regulate. But he also doesn’t view regulation as inherently bad. The public benefits greatly from regulation of food and transportation, for example. He also sees unionization as a key part of improving. A union would give designers cover and protection when bosses push them to implement unethical behavior. It also provides opportunity for training and professional development.

Ruined by Design paints a bleak view of the present while still providing hope for the future. Monteiro’s writing style is engaging and irreverent. The lessons he presents are valuable to anyone who makes product decisions. I strongly recommend this book to everyone.

Other writing: August 2019

What have I been writing when I’m not writing here?

Stuff I wrote

Fedora/Red Hat

Lafayette Eats

Stuff I curated

Fedora/Red Hat