> Since you have the experience I am very curious about one aspect of this, does the fact that some fellow contributors are paid have a noticeable effect on volunteer contributors.
I realize now that we're talking about different meanings of the term infrastructure. My organization offers co-location and hosting services to a variety of open source projects. You can think of us as sysadmin to the open source community. And for all the talk about funding developer time, discussion about the operations side is notoriously quiet. There's a few good actors that help us out, and we're trying to raise awareness of the issue.
Within our org, we try to contribute to open source as we go, and we have a software development team, but we're not paying people to write software for specific external projects. AFAIK, nobody is demotivated by our existence. You just don't see a lot of volunteers to get paged in the middle of the night when the website is down.
The open source software we fund development of is largely to suit our operations team needs. They're not the sort of software projects you'd expect people to volunteer for, which is why we allocated student developers to start them. It's hard to separate the compensation effects on volunteers from the general 'I don't run this software' effects, and since we didn't inject money into existing projects, there's no debates about the inequity.
There's another unstated funding challenge: if you want to maximize value your money brings to open source, you want to find someone who can escalate their contribution. If you assume the Steve Hansons of OSS are already spending all their time contributing, handing them money supports the status quo, but handing money to students who would otherwise be flipping burgers brings new faces, and additional effort to projects. In a sense, it matters whether your charitable goal is to reward lifetime contributions, or to gift the community better software, and in small ways these can be contradictory. Especially if continued funding relies on demonstrating return on the gifts, merely perpetuating the status quo is a problem.
> I'd also be interested in how you'd feel having a donation of skilled engineer 20% time compared to money to hire someone less experienced but full-time.
So our model is to hire student employees. They're cheap, and we can be flexible around their schedules in ways other potential employers cannot. We participate in GSoC, and are open to contributions, but generally speaking what we develop is not relevant for home use. On the operations side of things, we participate in the Chef ecosystem, but there's a level of access and such that open source infra teams prefer to control access to. Do you want to publish what exact version of nginx you're running?
Ah, in retrospect that makes sense and I misunderstood.
> And for all the talk about funding developer time, discussion about the operations side is notoriously quiet. There's a few good actors that help us out, and we're trying to raise awareness of the issue.
> You just don't see a lot of volunteers to get paged in the middle of the night when the website is down.
That's a great point, that's some good work you are doing and I'll admit that I needed my awareness raised on that issue as well. Thanks.
> In a sense, it matters whether your charitable goal is to reward lifetime contributions, or to gift the community better software, and in small ways these can be contradictory. Especially if continued funding relies on demonstrating return on the gifts, merely perpetuating the status quo is a problem.
Well put, I'm a believer in the end goal being better free software and rewarding contributors is a (complex and risky) means to that end.
Good points about the benefits of bringing in juniors and the subtle but important differences between openness at different architectural layers as well.
I realize now that we're talking about different meanings of the term infrastructure. My organization offers co-location and hosting services to a variety of open source projects. You can think of us as sysadmin to the open source community. And for all the talk about funding developer time, discussion about the operations side is notoriously quiet. There's a few good actors that help us out, and we're trying to raise awareness of the issue.
Within our org, we try to contribute to open source as we go, and we have a software development team, but we're not paying people to write software for specific external projects. AFAIK, nobody is demotivated by our existence. You just don't see a lot of volunteers to get paged in the middle of the night when the website is down.
The open source software we fund development of is largely to suit our operations team needs. They're not the sort of software projects you'd expect people to volunteer for, which is why we allocated student developers to start them. It's hard to separate the compensation effects on volunteers from the general 'I don't run this software' effects, and since we didn't inject money into existing projects, there's no debates about the inequity.
There's another unstated funding challenge: if you want to maximize value your money brings to open source, you want to find someone who can escalate their contribution. If you assume the Steve Hansons of OSS are already spending all their time contributing, handing them money supports the status quo, but handing money to students who would otherwise be flipping burgers brings new faces, and additional effort to projects. In a sense, it matters whether your charitable goal is to reward lifetime contributions, or to gift the community better software, and in small ways these can be contradictory. Especially if continued funding relies on demonstrating return on the gifts, merely perpetuating the status quo is a problem.
> I'd also be interested in how you'd feel having a donation of skilled engineer 20% time compared to money to hire someone less experienced but full-time.
So our model is to hire student employees. They're cheap, and we can be flexible around their schedules in ways other potential employers cannot. We participate in GSoC, and are open to contributions, but generally speaking what we develop is not relevant for home use. On the operations side of things, we participate in the Chef ecosystem, but there's a level of access and such that open source infra teams prefer to control access to. Do you want to publish what exact version of nginx you're running?