How to help your favourite open source project

So, you’re an engineer at FooCorp, or the hot new startup Barrrrr. You use a lot of open source, and you feel like your company isn’t really giving back enough to the community for the benefit it’s receiving. You feel generically guilty about this but aren’t really sure what to do about it, and aren’t really sure what the developers of those open source projects need or want.

As a developer of a reasonably popular open source library, I can tell you what I want from my corporate users:

It’s money. I’d like money.

This isn’t because I’m greedy and want to be swimming in a giant vault full of coins. I mean I’d not say no to the vault of coins, but if that was what I wanted there are a lot better ways to get there. The reason I want money to work on open source is that I want to work on open source, and I require money in order to survive. I think making it your day job is the dream of most of us who work on open source, but very few of us get to do that.

The thing is, I don’t want your money. People occasionally ask me how they can donate, and the answer is that they can’t. It’s just not a viable model. Individuals can’t and shouldn’t really donate enough money to make funding open source work viable. Things like Patreon work great if you’re doing something with sufficient mass appeal that you’ve got thousands of users willing to donate. Very few open source projects are in this category, and even if they were, I wouldn’t really feel any better about companies making profits off their employees’ individual donations than I would about them making profits off my free labour.

Companies could donate. Ned Batchelder wrote about this recently. He’s more optimistic about this than I am. Most companies can’t even be persuaded that they should upstream patches they make to open source, let alone that they should give their hard-earned money away.

So, what I would like instead is for companies to pay open source developers for services: Support contracts, custom development, training, etc. Long-term, this isn’t optimal, but it works now, which as someone who exists now rather than in the future, let me tell you is a big plus.

So what can you,  the aforementioned engineer at FooCorp/Barrrrr do in order to make this possible?

You might think that the answer is “advocate for it internally”. After all, you don’t have control of budget, so the thing to do here is to persuade people who do.

This can work, but it’s quite hit or miss. It can expend a lot of political capital, and you’re often not the best placed to argue for it.

Instead I would like to propose a simpler solution: Make introductions.

As an open source developer, the single most useful thing you can do for me if you do not yourself have control of budget is introduce me to someone who does. Ideally someone reasonably technical – if you’re a small enough company that you have access to the CTO, the CTO is a perfect person to do introductions to. If not, development managers or people who organise training are also great choices.

How do you do this?

Well, it’s quite straightforward:

To the CTO/etc: We’re using some projects that we think we could be using it more effectively, which would save us a lot of time and effort. Would you be up for an introduction to the developers of some of these projects to talk about how they can help us do so?

To the developers: We’re using your project. We’d like to give you money in exchange for your helping us use it more effectively. Is this a thing you would be interested in talking to someone over here about that?

The developers might say no, and that’s OK. Especially people who have full time jobs may not be able to find the time for this. But it can never hurt to ask, and I think most of us will say yes.

The CTO/etc might say no, but they shouldn’t. The maths is very simple: You have a lot of developers. Learning is slow and developers are expensive. If you can save each of those developers 1-2 days of time, that’s N-2N developer days of money saved. Paying an expert for a couple of days of even very well paid work is likely to cost you significantly less than that. Pointing this out to them may be useful.

Pointing out the sort of numbers involved to the open source developers in question may also be useful. It certainly would never have occurred to me prior to getting some experience in this area that offering training days for £2000 would actually be a huge discount (by the way, I’m offering said discount until January 22nd 2016, so now is an especially good time to make those intros).

Note: You don’t have to convince anyone to do work or pay money. All you have to convince them of is the idea that it might be worth doing this, and that it’s worth talking about the possibility.

Sometimes this will work out, sometimes it won’t, but in the cases where it doesn’t there was probably very little you could have done that would have worked, and in the cases where it does work you’ve saved your company a large chunk of money and given back to the project that is helping you, all for really very little effort.

You don’t have to restrict this to companies you work at either! Mentioning this to your friends at other companies can be very helpful too: “Hey, I remember you saying you had $PROBLEM. Well we’re using $PROJECT for something related. Why don’t you check it out? The authors are generally available to help you out if you need some assistance getting started, and for a very reasonable price”.

Ultimately, on our side, this is the “turn your open source software into a consultancy” model, and it doesn’t work for everyone, but I think a lot more of us would be doing it if we thought we could, and for those of us who already are, making those introductions is incredibly useful, easy to do, hugely appreciated.

Or, in other words: Take me to your leader. Please?

This entry was posted in programming, Python on by .