I got a new ThinkPad X1 Carbon laptop for work. Of course I immediately installed Fedora 28 on it. Everything seemed to work just fine. But the laptop came with a ThinkPad Thunderbolt dock and when I went to go use it, I noticed the Ethernet port didn’t work. Then I noticed the USB ports didn’t work. But at least the HDMI port worked? (Full disclosure: I didn’t try the VGA port).

It turns out the solution was really simple, but I didn’t find a simple explanation so I’m putting one here. (Comment #17 of Red Hat Buzilla #1367508 had the basic solution. I hope this post becomes a little easier to find.)

The dock uses Thunderbolt which includes some security features. A package called bolt provides a management tool for this. Happily, it’s already in the Fedora 28 repo.

Last Monday, a weekend of rumors proved to be true. Microsoft announced plans to buy code-hosting site GitHub for $7.5 billion. Microsoft’s past, particularly before Satya Nadella took the corner office a few years ago, was full of hostility to open source. “Embrace, extend, extinguish” was the operative phrase. It should come as no surprise, then, that many projects responded by abandoning the platform.

But beyond the kneejerk reaction, there are two questions to consider. First: can open source projects trust Microsoft? Secondly, should open source (and free software in particular) projects rely on corporate hosting.

Microsoft as a friend

Let’s start with the first question. With such a long history of active assault on open source, can Microsoft be trusted? Understanding that some people will never be convinced, I say “yes”. Both from the outside and from my time as a Microsoft employee, it’s clear that the company has changed under Nadella. Microsoft recognizes that open source projects are not only complementary, but strategically important.

This is driven by a change in the environment that Microsoft operates in. The operating system is less important than ever. Desktop-based office suites are giving way to web-based tools for many users. Licensed revenue may be the past and much of the present, but it’s not the future. Subscription revenue, be it from services like Office 365 or Infrastructure-as-a-Service offerings, is the future. And for many of these, adoption and consumption will be driven by open source projects and the developers (developers! developers! developers! developers!) that use them.

Microsoft’s change of heart is undoubtedly driven by business needs, but that doesn’t make it any less real. Jim Zemlin, Executive Director at the Linux Foundation, expressed his excitement, implying it was a victory for open source. Tidelift ran the numbers to look at Microsoft’s contributions to non-Microsoft projects. Their conclusion?

…today the company is demonstrating some impressive traction when it comes to open source community contributions. If we are to judge the company on its recent actions, the data shows what Satya Nadella said in his announcement about Microsoft being “all in on open source” is more than just words.

And in any acquisition, you should always ask “if not them, then who?” CNBC reported that GitHub was also in talks with Google. While Google may have a better reputation among the developer community, I’m not sure they’d be better for GitHub. After all, Google had Google Code, which it shut down in 2016. Would a second attempt in this space fare any better? Google Code had a two year head start on GitHub, but it languished.

As for other major tech companies, this tweet sums it up pretty well:

Google would have closed it after they got bored with it, Facebook would have mind all of the data from it and started offering Resharper licenses to everyone and Oracle would have literally set it on fire while suing GitLab and BitBucket for infringement.

Can you trust anyone to host?

My friend Lyz Joseph made an excellent point on Facebook the day the acquisition was announced:

Unpopular opinion: If you’re an open source project using GitHub, you already sold out. You traded freedom for convenience, regardless of what company is in control.

People often forget that GitHub itself is not open source. Some projects have avoided hosting on GitHub for that very reason. Even though the code repo itself is easily mirrored or migrated, that’s not the real value in GitHub. The “social coding” aspects — the issues, fork tracking, wikis, ease of pull requests, etc — are what make GitHub valuable. Chris Siebenmann called it “sticky in a soft way.”

GitLab, at least, offers a “community edition” that projects can self-host. In a fantasy world, each project would run their own infrastructure, perhaps with federated authentication for ease of use when you’re a participant in many projects. But that’s not the reality we live in. Hosting servers costs money and time. Small projects in particular lack both of those. Third-party infrastructure will always be attractive for this reason. And as good as competition is, having a dominant social coding site is helpful to users in the same way that a dominant social network is simpler: network effects are powerful.

So now what?

The deal isn’t expected to close for a while, and Microsoft plans to seek regulatory approval, which will not speed the process. Nothing will change immediately. In the medium term, I don’t expect much to change either. Microsoft has made it clear that it plans to run GitHub as a fairly autonomous business (the way it does with LinkedIn). GitHub gets the stability that comes from the support of one of the world’s largest companies. Microsoft gets a chance to improve its reputation and an opportunity to make it easier for developers to use Azure services.

Let’s put this another way.

GitHub is Microsoft’s chance to really prove to you how much they value OSS and your code.

Flip side, if they screw this up, you all will definitely not forgive them for it.

For the longest time, I would just drop by the barber shop in the hopes they had an opening. Why? Because I didn’t want to make a phone call to schedule an appointment. I hate making phone calls. What if they don’t answer and I have to leave a voicemail? What if they do answer and I have to talk to someone? I’m fine with in-person interactions, but there’s something about phones. Yuck. So I initially greeted the news that Google Duplex would handle phone calls for me with great glee.

Of course it’s not that simple. A voice-enabled AI that can pass for human is ripe for abuse. Imagine the phone scams you could pull.

The potential for phone scams using Google Duplex is breathtaking. Ah to be young, morally unencumbered and in posession of a list of 200,000 retiree phone numbers! https://t.co/0zwUEj4v3k

I recently called a local non-profit that I support to increase my monthly donation. They did not verify my identity in any way. So that’s one very obvious way for causing mischief. I could also see tech support scammers using this as a tool in their arsenal — if not to actually conduct the fraud then to pre-screen victims so that humans only have to talk to likely victims. It’s efficient!

Anil Dash, among many others, pointed out the apparent lack of consent in Google Duplex:

This stuff is really, really basic, but: any interaction with technology or the products of tech companies must be exist within a context of informed consent. Something like #GoogleDuplex fails this test, _by design_. That's an unfixable flaw.

The fact that Google inserted “um” and other verbal placeholders into Duplex makes it seem like they’re trying to hide the fact that it’s an AI. In response to the blowback, Google has said it will disclose when a bot is calling:

That helps, but I wonder how much abuse consideration Google has given this. It will definitely be helpful to people with disabilities that make using the phone difficult. It can be a time-saver for the Very Important Business Person™, too. But will it be used to expand the scale of phone fraud? Could it execute a denial of service attack against a business’s phone lines? Could it be used to harass journalists, advocates, abuse victims, etc?

As I read news coverage of this, I realized that my initial reaction didn’t consider abuse scenarios. That’s one of the many reasons diverse product teams are essential. It’s easy for folks who have a great deal of privilege to be blind to the ways technology can be misused. I think my conclusion is a pretty solid one:

In 2018, if you can't say "here are the abuse scenarios we considered and how we addressed them", your product is not ready for launch.

The lesson of MS Office macro viruses was to ask “what could an asshole do with this API?”The lesson from Cambridge Analytica was exactly the same. Now, apply to machine learning, voice, and computer vision.

I was discussing this with some other attendees at the Advanced Scale Forum last week. Too many computer science and related programs do not require any coursework in ethics, philosophy, etc. Most of computing has nothing to do with computers, but instead with the humans and societies that the computers interact with. We see the effects play out in open source communities, too: anything that’s not code is immediately devalued. But the last few years should teach us that code without consideration is dangerous.

Ben Thompson had a great article in Stratechery last week comparing the approaches of Apple and Microsoft versus Google and Facebook. In short: Apple and Microsoft are working on AI that enhances what people can do while Google and Facebook are working on AI to do things so people don’t have to. Both are needed, but the latter would seem to have a much greater level of ethical concerns.

There are no easy answers yet, and it’s likely that in a few years tools like Google Duplex will not even be noticeable because they’ve become so ubiquitous. The ethical issues will be addressed at some point. The only question is if it will be proactive or reactive.

I have the great honor of being on the organizing committee for the LISA conference this year. If you’ve followed me for a while, you know how much I enjoy LISA. It’s a great conference for anyone with a professional interest in sysadmin/DevOps/SRE. This year’s LISA is being held in Nashville, Tennessee, and the committee wants your submission.

As in years past, LISA content is focused on three tracks: architecture, culture, and engineering. There’s great technical content (one year I learned about Linux filesystem tuning from the guy who maintains the ext filesystems), but there’s also great non-technical content. The latter is a feature more conferences need to adopt.

I’d love to see you submit a talk or tutorial about how you solve the everyday (and not-so-everyday) problems in your job. Do you use containers? Databases? Microservices? Cloud? Whatever you do, there’s a space for your proposal.

If you know me, you know I’m an open source person. I use, contribute to, and advocate for open source software. I’ve written dozens of articles for Opensource.com. But open source has a big problem: open source communities tend to value code above all else.

Code is undeniably an important part of open source software. It’s hard to have software without code. But there’s a lot more to it.

Software doesn’t exist for its own benefit; it is written to serve the needs of people. This means that activities dealing with people are also critically important. Project management, design, QA, community management, marketing, et cetera are all people functions.

This isn’t to say that the people functions are more important than code. Without code, those functions don’t have a whole lot to do. But they all inform how the code is written, shared, and used. A project that only ships code is about as useful as a project that ships no code.

Open source projects need to write code. But they don’t need to diminish non-code contributions. And they particularly don’t need to diminish non-code contributors. And most importantly, they can’t accept bad behavior from a contributor just because they write a lot of good code.

A while back I came across a post where a developer took code that ran in 5 days and shortened it to 15 minutes. My immediate reaction was to treat it as “I was doing the wrong thing, so I stopped doing that and did the right thing instead.” But it wasn’t so simple. The developer clearly wasn’t an idiot.

When someone writes a new thing, I default to assuming they’re bad at Google or would rather spend their time writing unnecessary code than doing the thing they’re ostensibly trying to accomplish. That’s not always the case, of course, but I’ve found it to be a sane default over the years.

But in this case, the post’s author clearly thought through the problem. The tools he had available were unsuitable, so he made a new tool. It works on a much narrower set of problems than the existing tools, which is why it can be so much faster. But it’s not so narrow that it will only work for this one time. It’s a good mix of general utility and specific utility.

I should disclose two things at this point: 1. VM is a friend and 2. I will receive a complimentary copy of the book in exchange for a technical review I performed. Now that I have fulfilled my ethical obligations, let’s talk about this book.

This is a very good book. It’s a book I wish I had years ago when I was first starting in open source. Brasseur covers understanding your motivations for contributing, determining requirements for a project you’ll contribute to, finding a project that matches those requirements, and getting started with your first contribution.

She assumes very little knowledge on the reader’s part, which is welcome. Don’t know the difference between copyleft and permissive licenses? That’s okay! She explains them both, including the legal and cultural aspects, without nudging the reader toward her preferred paradigm. Indeed, you’ll find no judgement of license, language, tool, or operating system choices. VM has no time for that in real life, so you won’t find it in her book either.

One of the better things about this book is that it is not really a technical book. Yes, it discusses some technical concepts with regards to code repositories and the like, but it puts great emphasis on the non-technical parts of contributing. Brasseur covers communication, community structure, and collaboration.

Forge Your Future with Open Source was not quite complete when I performed my technical review, but it was complete enough to know that this is an excellent book. Newcomers to open source will benefit from reading it, as will old hands such as myself. The final version will be published in June, but you can order a beta copy now through The Pragmatic Bookshelf.