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

Using the wrong tool for the job

My first professional job was as a systems administrator in a small academic department on a large university campus. One of the worst parts of this job was dealing with the poster printer the department made available to students and faculty. It was self-service the whole way — users were expected to design and print their own poster. They could come to us for help when the printer malfunctioned (as it often did), but that was about it.

One of the results of this was that people, particularly the graduate students, did their poster design in PowerPoint. It was ubiquitous, it was familiar, and it produced something that looked poster-like. It also didn’t play nicely with the printer. PowerPoint was designed to make slide presentations, not 42″ wide posters. It’s not that PowerPoint posters didn’t work, it’s that they didn’t work quite right. The margins were a little off. Sometimes elements wouldn’t be quite where you expected them. It annoyed the hell out of me.

The wrong tool is easier

But as I’ve gained some experience, I’ve come to understand why people use the wrong tool for the job. It’s because the tool isn’t as wrong as it seems. Why should a graduate student spend time learning a design tool that they’ll use once per year when they can get a good enough result from what they already know?

Spreadsheets are the most widely-used database in the world (I’m guessing) because they’re ubiquitous and easy to start with. By the time you’ve outgrown what’s reasonable in a spreadsheet, you’re already committed. It’s why my post on date-based conditional formatting in Google Sheets is one of this blog’s most-read posts, even though it’s a poor fit for a spreadsheet.

People’s jobs are bigger than a particular task that they try to accomplish with a piece of software. Tools that require an up-front investment — even if that pays of over a short amount of time — are going to be a non-starter. This short-term thinking is natural. It’s not a user problem, it’s a management problem.

The wrong tool isn’t wrong

There’s also the case where what seems like the wrong tool is a failure to properly identify the problem. Take this tweet:

Using an excavator to row a raft down a river seems wrong. But what’s the goal? And what are the constraints?

Does it make sense to have an additional piece of equipment? How much more does that cost in time and labor? Is it even possible to get a powered barge to the location?

It’s an off-label usage of the tool, but doctors write off-label prescriptions all the time. Just because a tool isn’t right in a standalone context, when you look at the bigger picture it can be.

Hurricane Dorian forecast contest

Due to a technical error with the forecast submission script. the contest is cancled. I’m not sure I want to invest any more time in fixing this old and busted script, and I have yet to make good on my ten years of “I will rewrite it this winter”, so this may be the end of tropical forecast contests on Funnel Fiasco.

It’s that time of year again! Submit your forecast for mainland landfall by 0000 UTC on 29 August (8pm ET on Wednesday).

Is venture capital hurting the tech industry?

Maybe.

So many of the ethical lapses in the tech industry (think Facebook or Uber) seem to be driven, in part, by the need to grow as rapidly as possible. From where does that need come? At least part of it comes from the venture capitalists (VCs) who provide the early funding for those companies.

VC firms work by throwing a little money at a lot of companies, and throwing more money at the companies that are doing well, in the hopes that they go public or get acquired. Then the VC firms get big ol’ paydays. The nature of business is that most companies fail, so in order to keep going, the VC firms need the successes to be really big successes. Grow as fast as you can, profit and ethics be damned, until someone buys you for oodles of money.

To make themselves attractive to venture capital firms, fledgling companies will sometimes go for the flashy new technology. They’ll think about how they can disrupt industries with blockchain-based crypto-cloud-crowd-AI-machine-learning whatever-whatever-whatever. Everything has to scale exponentially. Throw in all sorts of sensors and have the device do local inference. Even if all they need is to put a stick-shaker on a steering wheel.

But this growth comes at a cost. Scaling a company culture is hard. Scaling it as fast as you can spin up a new AWS region is impossible. Free-flowing capital allows companies to build out quickly, but quickly isn’t always the same as well. Having restricted capital available is a constraint that can help a company make focused and deliberate decisions.

I’ve been thinking about this a lot recently. Not just because of my experience at a local pitch night, but because it’s just past the two year anniversary of Microsoft acquiring Cycle Computing. Jason and Rachel Stowe founded Cycle Computing in 2005 on their credit card. Apart from a debt round in 2016 (if I remember correctly), the company existed for 12 years on revenue.

It wasn’t always easy. There were times when I took a far-too-early flight because it would save the company fifty dollars. We had to be careful with our expenses and we couldn’t hire as fast as we wanted. But when we did spend money, it was because we thought it was the best thing for the company’s success, not just because it was there to spend. But that also meant that when the big payday came, the employees got a nice windfall — there were no VCs to pay off first.

Companies, particularly software and consulting companies that don’t need much equipment, can succeed in low-capital mode unlike anything we’ve known in the past. You don’t need office space because your employees can work remotely. You don’t need data centers because you can run on cloud services. Pay your employees and give them laptops, and then you’re off to the races. Capital infusion can help, but often it can make it worse. If you’re in business to run a successful business (as opposed to making big money), then maybe venture capital is not the answer for you.

As an industry — and a species — we’ve grown to love big, flashy numbers. But it’s important not to mistake valuation for value.

Business cards at conferences

Paper is dead; everything is digital.

Are you done laughing? Good! Stephanie Hurlburt posted a lengthy set of thoughts on using business cards at conferences, and it inspired me to think about how I use business cards.

I happen to be at a conference right now, and I brought my box of business cards with me. I’m sure I’ll only hand out a few, if any, but I prefer having them to not having them. If someone wants my card, I should have one available for them.

When I worked in marketing, I really liked getting business cards from prospective customers and partners. It made following up after the conference much easier. Sure, we had those nifty badge scanners, but some people covered their codes to protect from sneaky scans or they used a throwaway email address to avoid spam. But even if the scan worked, typing useful notes into the scanner is a tedious process. It’s much easier to pull out my pen and jot a few notes on the back of their card.

Now that I don’t work in marketing, the above scenario isn’t as important. But it’s easy to be insulated against the scenario arising.

What about digital methods? Sending someone an email or LinkedIn connection as you stand there works: unless it doesn’t. Conference WiFi can be unreliable, and mobile networks aren’t always great inside a large metal and concrete building. Taking pictures of business cards works, but it’s still harder to take quick notes, even with the stylus on my phone. I have a QR code that is a link to my LinkedIn profile saved on my phone. I have literally never used it.

Conferences are hard places to make connections. You’re busy and you meet so many other people that by the time you get home your brain is mush. For me, business cards are an easy way to preserve data. And sometimes they’re useful for winning a free lunch at a local restaurant.

Is it really open source if…?

I see this question asked (or stated as an accusation) with some regularity: “is it really open source if ___?” Fill in the blank with whatever. For example:

This conversation started with a criticism of GitHub restricting Iranian users in order to comply with US law. Like true Scotsmen, we all have a notion in our heads of what open source means, and the picture doesn’t always align from person to person.

Part of the problem is that there are two separate parts: the output and the input. The output is the legal part. The part that deals with licensing. That’s easy to deal with. Software is open source if it is presented under a license that meets the Open Source Initiative’s definition. Easy.

The hard part is that open source also has a cultural component to it. This is the input. There’s a community involved in the project. That’s often what people think of when they consider “open source”, but it also has no real definition. So we argue about it. A lot.

Is it really open source if you don’t allow it to be used by Iranians? No. That violates number 5 in the Open Source Definition. Is it really open source if you don’t allow Iranians to be in your community? Yes. Does that make it right? Well, that’s the real question we should be asking.

Other writing: July 2019

Stuff I wrote

Red Hat/Fedora

Lafayette Eats

  • El Maguey — A delicious Mexican restaurant in no hurry to get you to leave.

Stuff I curated

Red Hat/Fedora