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.

One thought on “Professional, vs Volunteer, Open Source”

  1. As a bespoke “nights and weekends contributor” this happens to me a lot. I’ve learned to live with it, but it sucks. It doesn’t help that things like GitHub promote the “heavy contributor status” over the “valued contributor” status. And a lot of people just _don’t care_.

    I am not fortunate enough that my job primarily involves the development of open source software. The major saving grace is that my day job doesn’t often involve me writing code, so my “code brain” can be used more for my contributions. But it’s tough to juggle.

    And it is increasingly common that I encounter people that treat contributors as more of a “necessary evil” than a “potential opportunity”. A lot of professional projects are also set up to give preferential treatment to corporate developers too. Who cares about passion and ethics?

    The only times I can work at the same pace as everyone else is when I take time off at work to work at *their* pace. Out of all the projects I work on, only one of them actually recognizes this problem, and it isn’t the one you’d expect. They actually take steps to solve that.

    The project in question regularly does hackfests/sprint events and sponsors community folks to meet up with paid developers. I can actually afford to meet everyone and get stuff done at their pace, or at least help set direction! But most projects I often work with don’t do that.

    As a consequence, the best I can do in most projects is try to watch the projects and make sure no one goes too off the rails. And I try to make sure my contributions are looked at and merged quickly, so that I don’t have to keep track of it for too long.

    When it comes to projects started and managed by Red Hat, I think it’s often forgotten that is the case, since the company is so large that they can be a self-sustainer by themselves, and thus people don’t know about all the projects Red Hat actually is the upstream for.

    Fedora has Flock, but that’s an artifact of a time when Red Hat was small. What about Spacewalk? Foreman/Katello/Pulp? CentOS (Dojos don’t count!)? Cockpit? FreeIPA? Keycloak/Ipsilon? JBoss OSS? oVirt? ManageIQ? PatternFly? Atomic/CoreOS? I can keep going here…

    Spacewalk itself is a great example of a poorly managed community project. It’s gotten to the point it was forked (as Uyuni), and that happened because interested developers and the community around Spacewalk couldn’t do _anything_ to interact and influence Spacewalk developers.

    Will Uyuni be any better? I don’t know. I’d rather see the damage repaired and the communities reunited. But there’s a lesson to be learned from this. And it _needs_ to be heeded. But I have a feeling it won’t be.

Comments are closed.