Draw what you want

I checked this book out from the library about sketching. It started with saying don’t let anybody tell you you’re doing it wrong. If they spent 40 pages telling me that I’m doing everything wrong.

There were a few good tips hiding in among that. But mostly it was just frustrating.

Hunting the Ibis

Hunting the Ibis
October 27th, 2019
Charles de Gaulle Airport, Paris

Even Google is in on it.
The recommended route from
Terminal 3 to Terminal 2
involves a train ride
a bus, an Uber
and a 37 minute walk.

I am, as Dave Barry might assure us,
not making this up.

Samuel Johnson not withstanding,
I am tired of Paris.

Not the Champs Elysees
or l’Arc —
I never made it that far.

CDG strives to offset
any good memories of Paris itself.
Life, it says, is not all roses.
Here, have some thorns.

During the war,
they painted over the road signs
to keep the enemy from
finding their way.

I come in peace.
The war is long over.
I seek only a place to sleep.

Hell is not, as JP tells us
other people.
No, it is wandering
Charles de Gaulle at 11:30,
looking for the Ibis,
as though it were not a cheap hotel,
but rather the bird of legend
flying mournfully over the rolling waves
looking for somewhere,
to land for the night.

Windstream is on my blacklist

Today I spent 90 minutes on the phone with Windstream Support for a 2-minute problem.

My dad bought a new DSL modem to replace the one that Windstream provided, so that he could own it and not have to pay a monthly rental fee. Smart move.

Ordinarily, the way these things work is that you unplug the old one and plug in the new one and everything just works. When this did not happen, I called Windstream Support, and there The Saga Begins.

The DSL light kept blinking for several minutes, indicating that it was not getting a connection to the internet service provider.

The first person that I talked to, told me that I needed to contact the hardware manufacturer who would connect in to the modem and change the configuration settings.

This is plainly not true. It is impossible for the hardware manufacturer to connect in if the modem is not connecting to the internet in the first place.

I called back and got a different person, who insisted that the problem was that I had a temporary email address attached to the account. That, also, was not true. And finally after over an hour of pointless back and forth, he finally escalated me to a level 2 network engineer.

The level 2 engineer looked up the model number of the modem that I was using and said that it was an ADSL modem and I needed a VDSL modem, and recommended an option. This took about 2 minutes.

I don’t know the difference between ADSL and VDSL, and, of course, as a customer, I shouldn’t have to.

My beef here is not with incompetent first line support. Of course they’re not competent. I don’t blame them for that. I understand that they are following a script to solve common problems. But intentionally training them to give misleading – and even completely false – answers is not okay.

My objection, rather, is with policies specifically designed to discourage people from owning their own hardware. If they make it as complicated as possible, they can continue to charge a monthly rental fee for equipment, rather than allowing people to control their own network infrastructure.

Someone without a technical background would simply give up at the first hurdle, and not bother trying to buy their own hardware. By making my parents feel stupid and incompetent, they could probably have tricked them into spending more money for something they didn’t actually need. This behavior is predatory and unethical.

Buying a new DSL modem should not be any more complicated than buying a new phone. You plug it in and it just works. Windstream is intentionally creating a situation where people pay more money for things they don’t need. Someone shouldn’t need a technical background or network engineer training in order to connect to the internet.

Reflections on the ASF board, and advice to new directors

Isabel recently asked some questions about serving on the Apache Software Foundation board of directors. Here’s my responses:

Which areas were a lot of fun for you?
This is a difficult question. I really can’t say that I serve on the board because it’s fun. Rewarding, yes. But not fun. It’s hard work (if you do it right). It’s time consuming. It’s frustrating. It makes some people angry with you. It brings out the very best in some people, and the very worst in others.
I’m very, very proud of being on the ASF board. Sitting in the company of these great women and men reminds me, often, that I came to this by chance, luck, fortuitous timing, and a lot of hard work, rather than by talent or accomplishments.
But I honestly can’t say that it’s fun.
Which parts were particularly educational for you?
The ASF has 200 projects, which are in every area of technology. We say that Apache is “tomorrow’s software, today.” And we have been inventing the future since the early httpd days.
Today, every area of technology that you care about has some of its origins in the ASF. (Sure, that’s probably an exaggeration, but not by much.)
Every piece of technology you use, every day, has some Apache in it. (This might also be an exaggeration, but I doubt it.)
All that to say, there are very few places at the ASF where you actually get to encounter all 200 of these projects. Those places are probably Infra, and the Board. These are the places where you are forced to learn what all of these projects are from a tech perspective, and how they operate from a social/community perspective. Every month I am reminded of a project that I had all but forgotten about – because there’s just so many of them.
Are there any parts of being a board member that you could imagine helping with even after stepping down?
 Honestly, almost all of them. But being on the board forces you to remain engaged, while, when you’re not on the board, there’s no penalty for letting them slip.
Any member can review PMC board reports and make comments on them. Any member can step up to provide mentoring and advice to projects that are struggling. Or even pitch in to solve technical problems, and thereby earn committer rights on that project.
Any member can provide thoughtful commentary on any board thread. Or dig through past archives for commentary already provided by previous generations of members and directors.
We have several former Board members who do this. Jim Jagielski, Greg Stein, and Roy Fielding come to mind as examples of this. And when they speak up, their input is always greatly valued because their past experience, combined with the perspective of stepping away for a moment, lend it more gravitas.
Which areas were particularly time costly for you?
Reviewing PMC reports can take as much, or as little time, as you’re willing to give it.
Certain former board members have mocked the PMC report review process, calling it empty rubber stamping. Other board members review the private@ and dev@ lists of each reporting project, every time, and make remarks like “This thread should have been on a public mailing list” and “Your report should have included a mention of this thread.”
Really, you can go to either extreme, but most of us fall somewhere in the middle, while varying from month to month based on time availability. Over all, each report seems to get adequate coverage most months, based on the average of board members.
I try, with each report, to check their previous report, see if there are unanswered concerns, and have a skim of at least the subject lines on the private mailing list for the past quarter.
Which areas were energy costly for you – didn’t necessarily take a lot of time but were definitely not fun to deal with?
Over the years, we have had a number of projects that don’t really get the ASF. It is the job of the board to nudge them gently back into the Apache Way when they stray too far. That’s usually not a big deal.
However, we have had other projects, or, at least, individuals within projects, who actively resist the Apache world view, working against it whenever possible.
This takes many forms.
We have had PMC members attempt to purge other members and committers who aren’t “pulling their weight”, or who are “stealing credit” by remaining on the committer list after becoming less active in the project.
We have had corporations attempt to cast the work of an Apache project as being owned, invented, or driven by that company.
We have PMCs that go either entirely rogue, or entirely AWOL, and simply refuse to respond to our queries or demands.
In these cases, it can take not only a great deal of time, but also a great deal of emotional energy, to try to guide these projects back into the right path. Particularly when that guidance is actively resisted, and, at times, mocked and ridiculed.
Now, granted, not all projects should be at Apache. Not all projects can or should fit into the way that we do things here. But if a project has decided that this is where they should be, and has endured the process of the Incubator, they cannot claim that they didn’t know what they were signing up for, and should be willing to work within those constraints.
I wish I had known this before joining the board
I wish I had known that I’d have to do budget stuff. Ye gods, I hate doing budget stuff.
In your opinion – what are the strengths of the ASF board?
The boards that I have served on (well, most of them anyway) have had a diversity of opinions, which we were able to express courteously.
(This has not universally been the case in every board term in the history of the Foundation, as illustrated by many amusing anecdotes which I cannot share here.)
There are people that served on the board with me, with whom I regularly disagree. That’s not to say that they are *wrong*, just that I often disagree with them.
The ability to discuss these opposing views, and sometimes persuade one another, is hugely valuable, and is something largely missing from public discourse these days. This is why I value it so much when I find it.
Even more important, the ability to disagree courteously, and still be able to stand one another, is a huge strength.
In your opinion – what are areas for potential improvement for the ASF board?
We are inexorably approaching the point where the number of projects makes quarterly reporting difficult to keep up with.
If you look at the board agenda, board reports are assigned agenda names alphabetically, like, Attachment A, Attachment B, and so on. During my first term on the board, for the first time we moved past Z and had reports AA, AB, and so on.
In the March 2019 board meeting, the last report was BX.
This is still manageable, if projects get their reports in on time, and directors start reviewing them early enough. But it’s getting tough. I have to pretty much plan an entire day to read board reports.
I don’t know what the solution to this is. There have been several proposed, but I don’t know that any of them are really ideal. We’re open to suggestions. The two most commonly proposed (more directors, more frequent board meetings) are not popular, for a number of reasons.
In your opinion – what changes should be made to the way the ASF board operates, interacts with communities, interacts with the wider ASF ecosystem, interacts with the public?
I don’t really have an answer to this. I think we’re doing find on this front, but, as always, we’re open to suggestions.
Any advice for new board members – where to look first, what legal implications to keep in mind, what PR implications to keep in mind etc.? What are the tasks and time commitment?
1) Attend board meetings, and read the board list, for several months before considering a run for the board. You may have an idea of what’s involved in being on the board, but actually watching it in action is eye opening.
2) When you’re on the board (or, indeed, when you’re a VP of the Foundation) every word you say is *heard as* the voice of the Foundation. It’s not, necessarily, but it’s heard that way. You don’t get to have your own personal views, and then claim that you’re not speaking on behalf of the Foundation. This is because, when you speak, reporters (and Twitter, and Facebook, and random conference attendees, and people just looking for dirt) will see right past you and attribute your views to the Foundation at large. “ASF Director and VP of Whotsits mumble mumble said today …”  Every time I see my name show up in a Google Alert, my very first thought is “What stupid thing did I say this time?”
3) If you think “as a Board member, I could do X”, consider just going ahead and doing X, as an ASF member. There’s almost nothing that you can do as a Board member, which you cannot also do as a member of the Foundation.
Tell us about a moment from your time on the ASF board that is most precious to you.

Shower in Singapore

Over the years I have marveled at the poor design decisions in hotels around the world, from the “half wall” shower enclosures to those ones where the entire bathroom area is the shower. Here’s the latest entry in the contest – my bathroom in my hotel in Singapore. This one warrants a video.

No name randos

I’ve been stewing on this all morning.

There’s two issues here.

The obvious one is, of course, that Máirín is a design powerhouse who does the work of 4 mortals, and this blowhard doesn’t know who she is. The disrespect here is stunning.

(For whatever it’s worth, I can’t find any mention of you on any of the Fedora mailing list archives. Are you sure *you* aren’t the no-name rando?)

But there’s – to me – the larger issue. Even if Máirín was a “no name”… even if she wasn’t brilliant and talented, this would STILL be incredibly inappropriate.

This kind of dismissal of new contributors is what leads to dead projects. Every project – every language, every nation, every company – is one generation from extinction. Failure to nurture the next generation is suicide by arrogance.

So the question here is, what do you even mean by “community” when you make statements like this? Do you mean that you want a comfy place for you and your 3 friends, or do you actually want to build something amazing that goes on after you are no longer involved? ‘Cause it sure sounds like you don’t have any clue about what it takes to foster a sustainable culture.

I’d also ask you, Thomas Alps, whoever you are, to cast your mind back to when you, too, were a “no-name rando”. If you had received this kind of hate at that moment, would you still be here?

Today’s no-name randos, as you so charmingly call them, are tomorrow’s core community. Or, more likely, not, if they receive this kind of welcome.

HDMI Capture on Fedora Linux

Yesterday I acquired one of these:

It’s an HDMI capture device. You can get one on Amazon.

The idea is that you plug it into any device that has HDMI output, such as your computer, video game console, etc, and you can then record that audio/video stream on your computer using standard video tools.

I got it so that I can produce better videos at the events that I host, such as the one next week in Brussels. The idea is that I can capture what’s getting sent to the main projector, and then merge it with the camera footage of the speaker, producing a video that has both sources of content.

Step one was getting it working on Linux, which was much easier than expected. I am running Fedora 29, but the techniques here should work on any Linux.

First I connected the device to the source as shown in the diagram:

In my case, I was testing with a PS4, but any HDMI source will work. The USB output, I plugged into my laptop.

Next, I installed OBS Studio. On Fedora, this is done via

sudo dnf -y install obs-studio

You can read more about OBS Studio on the project website. It’s clearly a very powerful piece of software, and I’m only using one feature.

In OBS Studio I created a “Scene” at the lower left corner of the app. (It doesn’t matter what you call it.) I then created a Source, selecting “Video Capture Device”, or possibly the actual name of the device, as the source, and “Camera 1” as the Input. You may need to fiddle with this depending on whether you have other cameras (such as a web cam) attached to your computer, which may change the naming/ordering of Inputs in that list.

Note that you can, if you wish configure several Sources at a time, so that you can, for example, record your gaming system, along with a picture-in-picture of your webcam, so that you can give running commentary. That kind of thing is popular on YouTube.

Finally, click “Start Recording”, which will create a .flv file in the location you have configured to save files. (By default, it’s in your home directory. Configure in File -> Settings -> Output.)

When you’re done, click “Stop Recording”, and you’re done. You can then edit that .flv file in your favorite editor. (I use kdenlive.)

Note that the resulting video will have the audio from the HDMI source, and also from whatever onboard mic(s) you have, so if that’s not your intent, set your system audio settings accordingly.

And, because I used my PS4 to experiment with, here’s some footage of me driving my Ferrari in Miami.

The eventual intent here is not just to record driving games (although that’s pretty cool) but, like I said, to produce more useful videos from the CentOS Dojos. So stay tuned to the CentOS YouTube channel, and *hopefully* in the next few weeks we’ll have video produced using this technique, including the slides and the presenter, complete with picture-in-picture format.

Blog stats

Re: this tweet from Cal:

I have been blogging for 17 years – at least, on this current blogging platform. In that time, I have posted 2,276 Posts, which gives an average of 11 posts per month.

Looking back to the early days – especially 2002 – it looks like I was blogging multiple times per day, sometimes.

In recent years, it’s been a lot slower. In fact, it looks like in 2018 I posted just 16 times. Which is, to be honest, a lot more than I thought I had.

Each year I determine to Facebook and Tweet less, blog more. By around March I seem to have lost the determination. This year, maybe I’ll do better.

Why did you reject my talk?

Inspired by Cal’s recent Twitter thread about conference talk rejection, I have been thinking about why conference talks are rejected.

I’ve been participating in running conferences and other events for more than 15 years, in one capacity or another. The part of the process I most dread is when you get the email from the rejected speaker.

“Why was my talk rejected?”

Or, even worse:

“Can you give me some tips that will help me get my talk accepted next time?”

The trouble is, that’s just not how any of this works.

It is almost never the case that talks are rejected. Rather, they are not accepted. This may seem like sophistry, but it’s really true.

For the normal event that I am involved with, we get anywhere from 2 to 5 talk submissions for each available spot in the schedule. A conference is bounded by space, time, and budget limitations that say that you can only have N talks at the event. N is often eroded even further by the need to have keynotes, sponsored sessions,  invited presentations, coffee breaks, and so on.

The upshot is that for every talk you schedule, you’re going to have to reject somewhere between 1 and 4 other talks. As much as you want to, you just can’t schedule everything, even when they’re all awesome.

Now, at the start of the process, there are in fact a few clunkers – talks that you’ll reject because they’re awful, off-topic, spam, or offensive. That’s easy, and I feel no remorse whatsoever about those ones.

The next step is harder. You have to decide what kind of story you want to tell with your content. You want to select a schedule that allows the attendee to take a journey. Perhaps it’s from beginner to expert. Or perhaps it’s a tour of a particular topic, covering all of the high points, and a handful of the deep-dives. The more sessions you have submitted, the more you can craft that story.

This allows you to have an event that crafts a narrative, rather than just having a pile of talks. That, in turn, means that you might schedule a talk that is a 9 out of 10, while dropping a talk that is a 10 out of 10, but which doesn’t fit the narrative, or which is a duplicate of content in another awesome talk.

When you’re done, you have your list of accepted talks, and then you have everything else.

This DOES NOT MEAN that the “everything else” was crap. It means that it didn’t fit the story that you were trying to tell.

And so you send out the reject notifications that say something to this effect:

We regret to inform you that your talk was not accepted for our event. We get a lot of submissions, and have a very limited number of sessions to schedule. Unfortunately, we were not able to include your talk in that selection.

So when you get the followup email asking for the reasons that the talk wasn’t accepted, that’s never, ever, an easy question. Often there isn’t any answer at all, because the selection had nothing whatsoever to do with the talk that was not accepted, which may have been awesome. There’s really nothing they could have done differently.

If there’s one answer I can offer, it’s that you should collaborate with other submitters to craft a story. Get together with your community to decide what story you want to tell, and craft 3, 5, 10, 20 talks that tell that narrative, and present them to the event producers as a track, or a mini-conference, and explain what story you’re trying to tell with the track.

Are you training? Educating? Recruiting? Persuading?

If you attend these talks, in this order, you’ll go from being a Java newbie to being able to write a functional application.


If you attend these talks, in this order, you’ll understand all of the important technologies in HPC, and how they interrelate.

That’s compelling, and I’d schedule that.

But if your talk is an island, unrelated to any other content at the event, even if it’s an awesome talk, chances are I won’t schedule it, because this isn’t about you. It’s about the event’s audience, and what they will take home with them.

And this is why, at ApacheCon North America 2019, I’ve asked ASF projects to sign up to run their own track, summit, mini-conference, or whatever they want to call it, and craft their own story to tell in that track. I want to foster that collaboration, and encourage each community to decide what story they’re trying to tell.

Professional, vs Volunteer, Open Source

A few weeks ago, a colleague asked me what I believed to be the biggest threat facing open source today. I answered that I think it’s full-time open source developers, and the effect they have on part-time volunteer developers.

Long ago (it actually hasn’t been very long, it just seems that way sometimes) open source was developed primarily by part-time hobbyist developers, working on their evenings and weekends on things that they were passionate about. Sure, there were full-time developers, but they were in the minority. Those of us working a few hours on the weekends envied them greatly. We wished that we, too, could get paid to do the thing that we love.

Now, 20 years on, the overwhelming majority of open source development is done by full-timers, working 9-5 on open source software. (No, I don’t have actual statistics on this. This is purely anecdotally based on my daily observations. I’d love to see actual scientific data on this.) And those who are working nights and weekends are often made to feel that they are less important than those that are putting in the long hours.

Most of the time, this is unintentional. The full-timers are not intentionally marginalizing the part-timers. It just happens as a result of the time that they’re able to put into it.

Imagine, if you will, that you’re a evenings-and-weekends contributor to a project. You have an idea to add a new feature, and you propose it on the mailing list, as per your project culture. And you start working on it, a couple of hours on Friday evening, and then a few more hours on Saturday morning before you have to mow the lawn and take your kids to gymnastics practice. Then there’s the cross country meet, and next thing you know, it’s Monday morning, and you’re back at work.

All week you think about what you’re going to do next weekend.

But, Friday evening comes, and you `git pull`, and, lo and behold, one of the full-timers has taken your starting point, turned it in a new direction, completed the feature, and there’s been a new release of the project. All while you were punching the clock on your unrelated job.

This is great for the product, of course. It moves faster. Users get features faster. Releases come out faster.

But, meanwhile, you have been told pretty clearly that your contribution wasn’t good enough. Or, at the very least, that it wasn’t fast enough.

The Cost of Professionalism

And of course there are lots of other benefits, too. Open source code, as a whole, is probably better than it used to be, because people have more time to focus. The features are more driven by actual use cases, since there’s all sorts of customer feedback that goes into the road map. But the volunteerism that made open source work in the first place is getting slowly squelched.

This is happening daily across the open source world, and MOST of it is unintentional. People are just doing their jobs, after all.

We are also starting to see places where projects are actively shunning the part timers, because they are not pulling their weight. Indeed, in recent weeks I’ve been told this explicitly by a prominent developer on a project that I follow. He feels that the part timers are stealing his glory, because they have their names on the list of contributors, but they aren’t keeping up with the volume of his contributions.

But, whether or not it is intentional, I worry about what this will do to the culture of open source as a whole. I do not in any way begrudge the full-timers their jobs. It’s what I dreamed of for years when I was an evenings-and-weekends open source developer, and it’s what I have now. I am thrilled to be paid to work full time in the open source world. But I worry that most new open source projects are completely corporate driven, and have none of the passion, the scratch-your-own-itch, and the personal drive with which open source began.

While most of the professional open source developers I have worked with in my years at Red Hat have been passionate and personally invested in the projects that they work on, there’s a certain percentage of them for whom this is just a job. If they were reassigned to some other project tomorrow, they’d switch over with no remorse. And I see this more and more as the years go by. Open source projects as passion is giving way to developers that are working on whatever their manager has assigned, and have no personal investment whatsoever.

This doesn’t in any way mean that they are bad people. Work is honorable.

I just worry about what effect this will have, and what open source will look like 20 years from now.

The Margin Is Too Narrow