I’ve been stewing on this all morning.

https://twitter.com/mairin/status/1094653366624501761?s=19

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.

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.

Re: this tweet from Cal:

I have been blogging for more than 13 years. Overall, I have averaged 3 blog posts per month in that time. #imOld

— Uncle Cal (@CalEvans) January 22, 2019

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.

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.

Or

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.

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.

We watched Blues Brothers last night.

Like many movies that have been hyped and built up to me over the years, this one completely failed to live up to the promise.

The premise of the movie is that Dan Aykroyd repeats a particular kinda funny line a dozen times, and lots of famous people are in unexpected situations.

I suspect, that if I had watched Saturday Night Live more as a kid that the movie would have had more appeal. I didn’t, and it didn’t.

So I give this movie a B+ for a pretty decent, if utterly absurd, car chase at the end. But a D in all other respects. The plot was weak and the acting was terrible.

Ironically, as is often the case in situations like this, I think I actually would have enjoyed the movie more had it not been promised as the greatest movie of all time for so many years, by so many people.

This is the second year that I’ve attended isc-hpc in Frankfurt. One of the highlights of this event is the student cluster competition. This year there are 12 teams competing for the fastest and most energy efficient student cluster.

This year I interviewed about half of the teams. It’s hard to find a time when they’re not actively working on projects, and one doesn’t want to interrupt.

There are several parts to the contest. In addition to solving some simulation problems that they’re presented with months in advance, there is always a secret application that is provided when they arrived on site. They have to program and optimise the solution, and then try to run it faster than any of the other teams. And, they have to do all that without exceeding 3 kilowatts of power usage.

This year there are teams from Africa, Asia, South America, and Europe.

The awards ceremony is this afternoon, when will find out which one of these teams of young student geniuses will prevail.