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

Does open source benefit independent developers?

Patrick’s heresy is not an unreasonable statement. My current employer grew to a $34 billion market value using, creating, and supporting open source software. But there are plenty of stories of open source developers working on key projects that are barely able to sustain themselves.

Benefits of use

It’s clear that independent software developers benefit from using open source software. If nothing else, the programming languages themselves are immensely beneficial. Much of the tooling, frameworks, and libraries used for developing applications these days are available for free under open source licenses. The economic barrier to entry would be much higher if everything had to be paid for.

Benefits of development

This is where the answer becomes more qualified. Contributing to open source projects can open the door to being hired at one of the businesses that make good money. But that’s not attractive to everyone. And an “everything should be free” mindset can make it hard to earn money.

It comes down to what you want to get out of it. If you’re doing it to make money, then it might not be beneficial, unless it’s a boost to your resume. But for some people, contributing to open source projects is a hobby they enjoy. I got started out of a sense of giving back to the community that provided me with a free operating system. The fact that it eventually became a paying job is a nice benefit.

Harm of not contributing

The flip side of the question is “does not contributing to open source harm indie developers?” The answer is “yes” far too often. A lot of development positions explicitly or implicitly expect your GitHub profile to be a key part of your resume. But not everyone has the privilege to be able to contribute to open source projects in their spare time. Hopefully that understanding spreads more broadly through the industry.

Switching from consumer Gmail to G Suite

Last spring, I was having some trouble with my email. I had my @funnelfiasco.com email forwarding to the Gmail account I’d been using since 2005 or so. But for some reason, every so often email would silently just not make it through. This nearly cost me the opportunity to be the technical reviewer for The Linux Philosophy for SysAdmins (affiliate link). There was no real indication of what was going on, and since my friend graciously hosts my site for free, I didn’t want to push too hard. So I decided I’d just be Google’s customer instead of their product.

Here’s the kicker: Google doesn’t let you just become a paying user. So I created a G Suite account for FunnelFiasco, a “company” of one person. But this also meant that I couldn’t just magically promote my existing account. Instead, I had to migrate all of the data. This turned out to be mostly easy, but a bit of a pain in some regards.

Migrating

Chrome

Moving Chrome data to a G Suite account is very easy: you log out and log in with the new account. The main thing to remember is to not deleting the existing data when you log in with the new account. It’s that simple. If you have any payment methods stored, those are in Google Play, not in Chrome.

Voice

Moving Google Voice is less easy. You can’t import your history into the new account, which killed a lot of the value for me (that was part of the reason I decided to port my Google Voice number to my mobile carrier). You can export it and keep it locally, but that’s not entirely helpful. But once I made peace with that, I was able to transfer it to my G Suite account. However, the Google Voice support site says that’s not an option these days.

Contacts

It’s as simple as exporting from the old account and importing to the new. It took a little while for my imported contacts to show up, which led me to think the import failed. So I tried again. And then I had all of my contacts twice. So I deleted them all and imported again. This time I was patient, and it was fine. But if you switch the main Google account on your Android phone, you may be surprised when an edit to a contact doesn’t appear to be reflected on your phone (it’s still showing the old account’s version, too).

Mail

G Suite provides a data migration service for importing email. This worked very well, but very slowly. One of the benefits of Gmail, especially in the early days, was the bountiful storage space. Combined with usable search, it meant not having to delete email. So I had something like 383,000 emails in my account. This took about 10 weeks for the data migration service to import. There are probably faster ways to do this, but I didn’t really care. If I needed an old message, I could log in to the old account.

The data migration service does not move mail filters. Those can be exported as an XML document and reimported to the new account.

Calendar

I apparently didn’t take notes on this at the time, but I think what I did here was to add my G Suite account as a fully-privileged user for my consumer calendar. I had them both displayed and as I saw things that were owned by the old account, I moved them to the new calendar. Most of my calendar events are on the shared family calendar anyway, so making my new account an owner there was essentially no different.

Docs/Drive

As with the calendar, I had to add my new account as owner to the documents I still cared about. It’s an annoyingly manual process.

Other services

I didn’t have much data — if any — in other services (YouTube, etc), so I didn’t worry about that.

Life with two Google Accounts

In the end, I’m sort of stuck with having two Google Accounts. Most people don’t email me directly at my @gmail account because I’ve been using @funnelfiasco.com for so long. But the account still exists and I go check it every so often to make sure I’m not missing anything. The few people who use Hangouts Chat still mostly IM me at the funnelfiasco account, but occasionally they’ll slip up and use the gmail account.

G Suite is overkill for my needs, but it’s the only way Google will take my money. At some point, I’d like to extricate myself from Google to some degree. I know it’s possible, and I know many of the people who might read this post would strongly advocate it. But it’s also very convenient to use Google, and I’m aware of the trade-offs I’m making. I’m not interested in having that conversation.

I cry at work

The new podcast “This is Uncomfortable” had an episode about crying in the workplace. I don’t have a lot to say about it, other than it’s a good story. But I wanted to go on record as saying that I cry at work.

Sometimes work is overwhelming. Sometimes my personal life leaves me on edge. Sometimes I read a moving article.

Sometimes I cry. It’s okay to feel things.

Adding more isn’t always better

Earlier this year, I attended a pitch night at my local coworking space. One of the teams that presented is working on a product to help prevent driving while drowsy. It’s a noble goal — drowsy driving can be as dangerous as drunk driving. Like drunk driving, people aren’t very good at self-evaluating their fitness to drive when they’re sleepy.

But as they talked, I sat there going “no. What are you doing?” They talked about learning who the driver is and establishing a baseline of their attentiveness to measure their drowsiness. All kinds of cool whiz-bang stuff. And maybe someday they’ll add some haptic feedback to the steering wheel.

I suggested that they target diabetics as a first market. Hypoglycemia is dangerous, too, and it’s an easily-defined audience, which helps in initial go-to-market efforts. When I talked to them after their presentation, they started talking about maybe adding blood sugar sensors.

No. Just no. I asked them if they’d considered what storing data might mean. It creates a liability for the driver in case of an accident. It could be used by insurance companies to change rates. It could be compromised and used for something else.

Using the latest tech is neat, but only when it makes sense. And sometimes, the more you add, the worse things get.

If you want a diverse community, you have to stand up for marginalized members

On Monday, The Perl Conference’s Standards of Conduct Committee published an incident report. In a talk at the conference, a speaker deadnamed and misgendered a member of the community. As a result, they took down the YouTube video of that talk.

The speaker in question happens to be a keynote speaker at PerlCon. The PerlCon organizers wrote a pretty awful post (that they have since edited) that essentially dismissed the concerns of the transgender members of the Perl community. They went on to mock the pain that deadnaming causes.

I did not think to save their post in the Wayback Machine before they edited it down to a brief and meaningless statement. “We are preparing a great conference and do not want to break the festival and trash our year-long hard work we did for preparing the confernece, the program and the entertainment program.”

What they don’t say is “we value the marginalized members of our community.” And they make that very clear. Editing out the insulting part of their post does not ,mean much, as VM Brasseur pointed out.

If you value an inclusive community, you have to stand up for the marginalized members when they are excluded. If you don’t, you make it very clear that you’re only giving lip service to the idea. As it is, the PerlCon organizers don’t even apologize. They’re more concerned about the bad publicity than the bad effect on the community.

Do your best

What does it mean to do your best? I was recently talking to a friend about this. She’s a single mother of four and at the time of the conversation was working part time while she completed her bachelors degree. She was upset because she felt like she wasn’t doing the best she could on a particular paper. This bothered her because she’s someone who always tries to do her best.

I said she still was. Just because she could have, in isolation, written a better paper, she’s still doing her best in aggregate. That’s one of the most important things I learned in grad school: how to let some things slide while keeping the overall effort.

Despite what years of motivational talks (and a poem called “Good Enough is Neither” that was drilled into us in ninth grade) have told me, sometimes good enough is good enough. It’s all a balancing act. Part of being an adult is knowing how to strike the balance between all of the things you have and want to do.

For folks with a singular pursuit, perhaps they can focus all of their energy on doing their absolute best in a single thing. For most of us, life doesn’t work that way. Your job isn’t one thing, it’s a collection of things that you do. This is even more true for your family and friends. Sometimes you have to do less than your best at one thing in order to do well enough somewhere else.

I tend to view “doing my best” not as something that happens on a single task, but as a reflection of my effort in the aggregate. I think that’s a healthier approach.

Naming your language interpreters and ecosystem

Last week, Fedora contributors proposed to change the meaning of “python” from “python2” to “python3” starting with Fedora 31. This makes sense in the context of Python 2’s upcoming demise. But some feedback on the mailing list, including mine, wonders why we’re perpetuating it.

Should there also be no “pip”, no “pytest”, no “pylint”, … command? I would say “yes”. Admittedly, it’s avoiding future pain in exchange for some current pain. But we’re already dealing with a disruption, so why enable the same issues when it’s time for Python 4?

This is bigger than Python, though. If you’re following semantic versioning, I argue that you should name your interpreters and any ecosystem executables with the major version name. Unless you’re promising to always maintain backward compatibility (or to just stop working on the project), you’re eventually setting your users up for pain.

What about non-programming languages? This is probably good advice for anything with a client-server model (e.g. databases). Or anything else where the command is separated from other components of the ecosystem. You could extend this to any executable or script that may be called by another. That’s not wrong, but there’s probably a reasonable line to draw somewhere.

Wherever you draw the line, doing it from the beginning makes life easier when the new, incompatible version comes out.

Other writing: June 2019

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

Stuff I wrote

Red Hat/Fedora

Lafayette Eats

Stuff I curated

Red Hat/Fedora

Opensource.com