Money, Money, Money... by Russell Keith-Magee

Alright, thank you very much. So hi, yeah, I'm Russell Keith McGee. Uh if you've heard of me before, it's probably because of my work on the Django project. I've been a core team member there for 10 years. I've probably been president of the Django Software Foundation since 2011. One of the big challenges of the Django project, and any big open source project for that matter, is has been to secure certainty in its long-term development future. My day job is as CTO and co-founder of TradesCloud. We're a software as a service for tradespeople, plumbers, electricians, carpenters, people like that. TradesCloud depends on a number of open source projects. Django, Apache, Memcache, uh countless others. So I've got a business interest in the continuity of these open source projects, but I certainly don't have the resources to fund them all myself. I've also got a declared interest in user interface and GUI

tools, especially as they relate to development tools. I've got all sorts of grand visions about what I'd like to do with the BWARE project. And I've received some great contributions from the community, but it's still largely my own work. But my startup would be able to make great use of these tools if they were mature I'm also the maintainer of some smaller projects, like the Python wrapper to the Xero API. I started the project because I had an itch. My itch has now been scratched, but I've open sourced the project, which means I've kind of inherited this maintenance task I've accepted help from a number of people, most notably Matthew Schinkel and Aidan Lister, who've done some great work, but if I'm completely honest, the maintenance burden of PyZero massively exceeds the amount of time that I personally can reasonably dedicate to it. So I've got vested interests in free software.

I've got interests in free software as a producer of a successful project with a high profile, as the producer of a small project with lots of users, but very little personal incentive. And as a producer of smaller projects with almost no profile, but all sorts of really grand plans. And these projects all have different resourcing needs, reflecting their maturity as projects. I've also got interests as a consumer of free software, both in terms of the software that I rely upon to develop my own projects and in terms of my commercial interest in the long-term maintenance of tools and platforms that I use. I need these platforms and these projects to continue to develop, to survive and thrive. Based on my experience, I'd like to make a very bold assertion. Absent of any other constraints, given equivalent resources, free software or the free software approach produces a vastly superior outcome than the closed source approach.

The catch here is the operative clause, given equivalent resources. Most free software projects aren't developed using anything close to equivalent resources of their closed source counterparts. Now in some cases this is a blessing in disguise, regardless of the process uh of the project. Having scarce resources is an excellent crucible for burning away the unnecessary to leave just the base metal. But it's not always a blessing Talk to any prominent free software developer, and amongst the success stories, you'll also hear some really consistent troubles. That they've got really great ideas and grand plans, but no time to execute. That they're about to burn out due to the pressures of maintaining their project. Or that they've had yet another mailing list discussion with someone who doesn't understand why you didn't drop everything to help them fix their problem.

And there are plenty of examples of this. OpenSSL is the software that drives pretty much every secure connection on the internet And yet it took the discovery of Heartbleed, a critical vulnerability that sent the internet into a tailspin before they could find funding to pay for maintainers. Another example, GNU PG, Vanna Kokh, almost went bankrupt trying to support GPG, a project that many other projects depend upon for their trust in their release process. Vana was was rescued at death's door by the Linux Foundation's Core Infrastructure Initiative. Now, those are both examples that ended with happy endings, with funding, but it's not all happy endings. Take the example of Capistrano, was a hugely popular configuration management tool around 2007-2008, maintained by Yamas Bak. In 2008, citing burnout and maintenance overhead.

He famously withdrew support for Windows, saying Windows may be the 800-pound gorilla in the room, but it's not my gorilla and it's not my room. This was an incredibly unpopular move amongst Windows users. But even with the scale down that came with that, Yamas burnt out in 2009, abandoning Capistrano wholesale and a number of other projects without maintenance. The thing is though, this is a community that has lots of cash. In the grand scheme of things, software development is a well-funded industry. If companies can find money for football tables and meditative ball pits, they should be able to find resources to help maintain the software on which they've based their success. And if you're on the receiving end of the problem, a developer of free software, that can be really frustrating. And for me, this is the really big unanswered question of the free software movement: how to reconcile the discrepancy between the clear demand for a software product

and the ability to convert that demand into the time and resources needed to service the demand. Now okay, well this in theory, the theory says everyone can contribute to a free software project. In reality, every single so project of any significance has leaders. And at the most basic level, it's whoever has the commit bit. And you need that leadership, especially when you do anything where design is involved. The running gag is that a camel is a horse designed by committee. The very worst APIs we deal with on a daily basis are the ones that were designed by committee. You need someone with taste running the show. But there's a bigger problem. There's the extent of the engagement that users have with a project. Here's a thought experiment to prove the point. We're in a room full of Python users. Django is a free software project. Who in this room has found a bug in Django or has a niggling thing that they'd like to see fixed with a Django API?

Just a show of hands. Okay, we're looking at probably about half the room. Who's turned that niggle into a bug report in Django? Yeah, most of those? Okay, that's pretty good. Who submitted a patch to Django for that niggle? Yeah, okay, so we're down to about a third of what was left there. Of those, who've had that patch committed? Okay, a couple. That's better better than better results than I got in Pycott Australia. So what's going on here? We've had a massive scale down from people who say they have a problem down to people who have had that problem fixed Well what's going on here? It reflects two different ways of looking at a piece of software, projects and products. And it's a matter of personal perspective. My project can be your product and vice versa. When I look at a piece of code as a project, it's a body of code where I'm contributing to a larger goal. I'm willing to spend my resources focusing on other people's needs

in the hope that their needs will help make the project as a whole better. I'm willing to do this because I get some personal gain, like an enhanced public profile, or if the tool is really close to my work coalface, or if I know that I can make a really substantive contribution. But the further I get away from my coalface, the harder it is to make a contribution, the less inclined I am to even want to contribute to a project. Most of the time, it's a product that I'm using What's an all? If a product has bugs, I work around them. I find an alternative, rather than navigating the contribution process to contribute a patch back upstream. In the case of a product, the freedoms that are afforded by free software are a bit like freedom of speech. It's a freedom I most definitely want. It's comforting to know that it's there, but I don't spend every day making sure that I fully exploit the extents of those freedoms.

There are people who do protesters, advocates for controversial social positions, and one day, given the right circumstances, I might join in and help them. But most of the time, I just want to be pragmatic and get on with living. The dichotomy between the theory and the practice is also the reason why comments like patches welcome get made in free software mailing lists. On the one hand, it's completely correct, anyone can contribute to an open source project, and on most projects, patches are welcome But most people don't look at a new open source project as an opportunity to engage with the development process. Most people just want to use the damn software. And you can argue that this is because people are focusing on the wrong interpretation of free and haven't captured the spirit of free software. And again, that's 100% true, but utterly counterproductive as a position.

Anyone who's done any UX work knows that if users are consistently making a mistake with your user interface, blaming the user gets you nowhere. You were in charge of what the user experienced. They made the error because of a fundamental cognitive disconnect And even if everyone did get the right message, let's be realistic, it wouldn't work anyway. The Mythical Man Month showed us you can't deliver a project faster by throwing more people at it. Nine women can't make a baby in one month. A project doesn't just need resources, it needs the right resources in the right quantities. And ultimately that means the project finding a way to get the resources they need to be self-sustaining. So that means if you want free software to be maintained and maintained well, we need to find a way to fund its maintenance. 18 years ago, Eric S.

Raymond published an essay entitled Cathedral and the Bazaar. That essay catalyzed the start of the open source movement, a sort of a redefinition of free software to make it clear that openness, not price, was the important property we were aiming for. What isn't as well remembered is that the Cathedral and the Bazaar wasn't the only essay that Raymond wrote at the time. He published two other essays shortly after the Cathedral and the Bazaar, one called Homesteading the New Sphere, about the social organization motivations behind free software projects and the magic cauldron about the economics of free software. One of the key distinctions that Raymond highlights in that essay is the difference between use value and sale value. Sale value of a product is its value as a saleable commodity, literally what you can sell it for. The use value of a product is its economic value as a tool, as a productivity multiplier. And this is how much economic benefit the user will get from a product.

The important thing you've got to know is that the two aren't necessarily connected. In a traditional manufacturing environment, the focus is on sale value because that's ultimately linked to manufacturing cost, the cost of parts and materials necessary to turn this thing off a production line. But most software isn't produced for sale value. It's in-house software produced for use value. And in the case of free software, the sale value of free software is zero. That doesn't mean though that the use value is zero. And the catch is working out how to exploit the use value that exists within an organization and using that as the monetization channel. Okay, so what are the options you have? Well, start easy. You can sell merchandise, and this is really easy to do. Throw a thing up on Teespring, you're selling t-shirts. But let's be honest, you're not going to fund your software empire by selling t-shirts.

Okay, you can get your users to pay for documentation. Write a book, get users to pay for it. Okay. Unfortunately, the dirty little secret of the tech writing scene is that nobody gets rich writing books. Thank you, Andrew. They're incredibly valuable resources for the community. They're great for padding your resume, but they're not so great as a revenue stream. One area that does pay well is selling training. Employers are willing to pay big bucks for training courses. If you can put together a three-day intensive workshop, you can sell that again and again and again You can productize your offering. Source code remains free, but as a simple, easy-to-use installer, that costs money. And this works really well when what you have is a clearly identifiable product, something like say an IDE. One specific model of productization is software as a service. Give the code away for free, but pay for the convenience of someone else having it,

someone else administer it for you. Any open source web project is a good example of this. You can install the software on your own servers, yes, but honestly, unless you've got a reason to care, use someone else's hosted solution, give them money every month, let them take care of it for you. But software as a service is only really viable if you can deliver as a service, which means it's really only viable for web. Now in this community, that's not such a bad thing. But as a broader software engineering thing, not every software can be done, every piece of software can be developed as software as a service. And as technologies like Docker commodify development, it's possible that even this revenue stream might evaporate because the thing that's you act the hard part, the actual deployment. might be able to be completely factored out. Okay, so what else can you sell? Well you can sell access to the developers. If you're the maintainer of a project, you're in the best position to provide support or debug complex problems, which means you're in the prime position to sell support and consulting.

Hans Karl uh calls this the Ghostbusters uh business model. Who are you gonna call? You can sell access to the software itself, strangely. TrollTech did this with QT, Riverbank still does with PyC Py QT bindings The library itself is GPL'd, but if you want to use it on a closed source project, you can for a fee. Now this has the advantage that it forces commercial interests to actually pay for what they're using. But it also has a problem of discouraging smaller size-scale commercial tinkering. If I'm writing a new tool and I'm forced between open sourcing my tool or paying a $1,000 price tag, I might consider using a different option You can also get into the business of providing certifications and guarantees, auditing code to ensure quality or compatibility, providing guarantees about fixing bugs, certifying that individuals are skilled in the use of your product.

This is a big part of Red Hat's business model. Auditing packages, making sure they all interoperate as expected, ensuring that security updates are available, meet the same standards, certifying system administrators. There is this is a set of products that appeals to the enterprise end of town, and that's a really lucrative end of the market to get into. But those customers also tend to only want those guarantees for certain types of software, broadly speaking, boring fuddy-duddy software. Your operating system, your database, these are the pieces of software that must be rock solid in an enterprise setting. Your debug toolbar? Maybe not so much, unless it's being wrapped up in some other bigger suite of tools. Another problem with a lot of these revenue sources is that if you run your project well, a lot of them are ruled out or at least severely curtailed If you make something truly simple to use, you've just removed the market for books and training courses, or at the very least, moved the ground to advanced courses and advanced books, which are a lot harder to write and have a much smaller audience.

Django saw this firsthand. Django's documentation was famously very good from a very early stage. And as a result, it was very hard to get publishers to take on Django book projects because the documentation was too good. And was undermining the market for books. It's taken a long time and a lot of self-publishing and some very dedicated individuals, like Andrew sitting over here, to get good Django books available for sale. If you have a project mailing list where the community answers questions for free and it's a healthy, responsive mailing list, why would I pay for support? And if your software is well designed and modular and those interfaces are well documented and I need a modification, why wouldn't I just write the mod myself Now, okay, I am exaggerating there. There are legitimate reasons to pay for support to bring in a consultant, even if the interfaces are clean and well documented.

But my point is, the better you do your job as a free software engineer, the harder it becomes to make the business case for your revenue stream. Because the value proposition becomes a lot less obvious. And if it isn't directly undermining your value proposition, it can still undermine you indirectly, because the more time you spend earning money, the less time you spend paying uh you spend doing what the money is supposed to pay for. Administering a certification project, a program, takes time. Writing and developing training courses takes time. Consulting can be lucrative, but developing a sales pipeline takes time. And if you're consulting, you need to make sure that sales pipeline is full, which means you're going to err on the side of taking on more work than less, which means you've just closed the door on the time you have available to work on open source. You also need to be careful that in selling your business case, you don't undermine your main project.

If every hard question on your mailing list is answered with, well, we can answer that for a fee. You're gonna start sounding like a shill. And if your project says it needs money to make sure you stay stay on top of security issues, well you have to be really careful how you say that. Because the easy interpretation is, well, this process project must be insecure because they're not on top of security now. There's also a question of scale. Python, Django, these are large projects with large communities. Making a business case for Python and Django isn't that hard. It's not trivial, but it's possible. But as the maintainer of a smaller project, again, say Django Debug Toolbar, are they seriously expected to write and sell a book about Django Debug Toolbar to pay for its development or training and certification in its use? Those revenue streams don't really exist. Smaller projects have no l are no less important to the vitality of the overall Django ecosystem, but those projects aren't afforded the opportunities for fundraising that larger projects have.

It's also important to realize that not all products are afforded these opportunities, these are opportunities for revenue. An IDE can be productized. A developer library, probably not. Different projects need a different mix of revenue streams. Okay, so can we do this without selling something at all? Free software stems from a moral imperative. So can we fund development through altruism and patronage? Well, yes, it's harder, but there's evidence that it can be done. One option that's seen a lot of activity recently is crowdfunding. Platforms like Kickstarter, Indiegogo provide a way for a group of people to pitch in and contribute to a goal. Django community has got a couple of examples of really successful crowdfunding projects. Each raising tens of thousands of dollars. But if you survey the people who did these projects, they didn't really make money on those projects.

The amount of engineering time that went into them really exceeded the amount of money they raised Another idea that gets floated regularly is the idea of bug bounties, placing a price on specific bugs. Now this is really just another form of crowdfunding. You want a specific bug fixed or a feature added? Contribute money. You really want it, contribute some more. And eventually someone will take the bait and fix that bug or implement that feature. And it's an attractive model. But it also has some really big problems. Most notably, who gets paid? Do you pay by lines of code written? Well that ignores the contribution of reviewers. How much more important than writing code is reviewing code or triaging a bug or writing the documentation? But the biggest problem that I see with crowdfunding approaches is that they're in conflict with establishing a working income. If you're hiring yourself out, the shorter the engagement, the higher your hourly rate.

This is a hedge against unemployment at the end of your contract. If you're doing a Kickstarter, you're best served by having a very small, clearly described, clearly achievable goal, so a month or two of work if possible. That means you need to charge your short-term rate in order to hedge against your long-term income. But it's also in your interest to have a low fundraising target so that the campaign actually tips and seems achievable. If it's too high, it can scare off potential bidders. It also means that the community is paying a premium for the development of new features, which isn't the best use of an already scarce resource. Okay, so if you want longer-term income, you need to start looking at longer-term engagements. This means you have to stop looking at funding specific projects and start looking at funding the person with grants and fellowship positions. I'm including Patreon in this list because it's effectively crowdsourced

patronage. You're not paying for a specific thing, it's keep doing what you're doing money. Now, over the last 10 months, Django has been using this model. We hired a fellow at the end of last year, and the fellow, his name is Tim Graham, is responsible for keeping the project wheels greased. From a technical perspective, this has been a roaring success. Tim's made great inroads into our ticket backlog, and the response times on ticket reviews are lower than they've ever been. The hard part has been raising the money to pay him. We did a fundraiser at the start of the year specifically to fund the fellow. The campaign raised about $50,000. That's no small chunk of change, but it's also not a lot when you're talking about a full-time employee. We're going to need to do another fundraiser really soon if the fellowship's going to continue Almost everyone agrees it's been money well spent, but converting that into donations has been hard work. We're about to relaunch that fundraising campaign so that we can all contribute and hopefully be able to contribute, well we will be able to contribute that on a continuing month-by-month basis.

So that we can hopefully build an established income that we know we have every month to spend. Another approach of raising money is to embrace the devil and go commercial. Commercial interests have the money, so why shouldn't they pay for it? And this can be very successful under certain circumstances, but you also have to make a business case for the corporate owner. OpenStack's a great example of this. Why are Rackspace, HP, Red Hat, Ubuntu all interested in OpenStack? Because they sell products that benefit from commodifying a hosting environment. By making it cheap and easy to control cloud deployments, they increase the size of the market for cloud-cloud hosting, which means more money for them. Node. js is funded by Joint for similar reasons. joint is making a long play that it's easier to develop web software, more people will write web software, increasing the market for joint services. But Node is also a cautionary tale about corporate interests. What happens when the community and the corporate sponsor disagree about the direction of a project?

Well, you get project splits like IOJS. Corporate money can corrupt. You need to be careful that project governance is independent of your funding source. Having a single corporate master also puts the project at risk if that corporate master loses interest. Django was originally under the wing of the World Company. Eventually that interest waned and the corporate support dried up too. The other corporate answer that gets floated is to go get venture money. And there are some great examples of people doing this. Meteor, for example, is funding the development of their platform with money from a venture fund. They've got plenty of money to hire engineers, designers, whatever they need. What makes me nervous about this model? We've been here before. Who here remembers Easel? Hey, there we go. Okay, so if for those who don't remember, uh late 90s, Easel was a dot-com company that was funded to develop the Nautilus file manager for GNOME And we got two years of great open source code.

And then the bubble burst and the company went bust because strangely enough, no one wanted to buy a company that produced a file manager. Now, the good thing is we still have the code, but it would be better to have that code still being actively developed. And again, this discussion is happening in an industry where billion-dollar valuations are kicking around. Large parts of our industry are built on a foundation of free and open source software, but without the those with the capacity to contribute, in many cases, aren't contributing. Some are. These are companies that do give huge amounts back to open source companies, but there are a lot of companies that don't give back. And even those that do give back, many of them give the help they're able to give, which isn't necessarily the help that is needed DSF, for example, regularly receives offers for free and subsidized hosting from hosting providers. And don't get me wrong, it's great and it's most uh incredibly helpful and very, very, uh, very, very useful.

But what we really need is someone on the payroll to pay to review bugs. Earlier on in the development of Django, we needed people to review new features. We're in a constant need for graphic designers and artists and tech writers. We need people who know how to do sysadmin. We need community outreach And we don't need a thousand people donating one hour, we need ten very specific people working 40 hours a week When a disaster hits, organizations like the Red Cross call for donations and they will usually say, please give us money, not tins of food or blankets. The reason? Money can buy what's needed. You can't control what people donate. And even if they do happen to donate exactly what is needed, there is a huge logistic task of working out what's been donated and how to get it where it's needed. Free and open source projects are much the same. They require resources. Some companies donate in kind and that's great, but it's really

exactly what is needed. And it's very easy to get distracted working out what to do with what has been donated, but you don't have an immediate use for And sadly, just as with charities, many companies just don't donate at all. And I'm not claiming these companies are being deliberately malicious in not funding open source. If anything, we as a community have failed them because we haven't helped them help us. Most importantly, we don't have a mechanism in place to make it easy to spend money and easy to receive money. The current state of affairs clearly demonstrates that it's not enough that there is a lot of money in a community. You have to make the mechanism for donating that money as obvious and seamless as possible. And you have to have someone to direct that money towards One model community that I think does this really well is the WordPress community. WordPress is GPL software.

There are books, videos, blogs on how to write WordPress plugins and themes, the same as there is for every open source community. But critically, there are also books, videos, and blogs about how to make a business writing WordPress plugins and themes. WordPress is GPL'd and therefore so are all the plugins. But they've got a store that you can go to to buy those plugins and get free ones and easily install them in your WordPress instance. The WordPress ecosystem has fundamentally embraced the fact that money needs to be part of the equation And then by doing so, they've created an industry that is self-funding. And this, I'd argue, is a big reason, or one of the big reasons, for the success of WordPress as a platform. In that vein, I'd like to make a very controversial proposal. What if PyPI was a revenue stream?

What if when I registered an application, registered a project with PyPI, I could specify a price Either per install per install, per version, per app, per month, whatever. And then when I pip install, the cost just gets attached to my my Pipe UI account. And I get a monthly charge on my credit card that gets passed back to developer projects If PyPI stats are being believed, Django is downloaded from PyPI more than a million times every month. You put a 10 cent toll on each of those downloads. That would raise $100,000 every month. Enough to pay for ten full-time well-paid developers or a metric buttload of diversity outreach, Django Girls, and Community Support You could also leverage the PyPI dependency information to pay it forward. If you're writing a project that depends on another project, you could opt to pass some of that revenue upstream or request that people or people or downstream projects provide a tithe.

And then there's the biggest dependency of all, PyPI and Python itself. If PyPI took a small cut of the revenue raise, that could help pay for the development and maintenance of PyPI and potentially Python itself. You can also take some of that money, collect it, put it into a development pool. So if there's a new project that needs some bootstrapping cash to get started, or an established project that needs some help for a big task, like a Python 3 upgrade, the community as a whole can funnel money towards that project Okay, what about people who don't have money? Well you can offer still offer free passes. You're at a Django Girl event, use this promo code to have free access. You can still give away your software at no cost, and it's still free software. You're still developing Python, so you're still going to get the source. You could probably even make the sign-up process completely optional. All you're doing is paving the cow path, making it easy to collect a toll on the easiest possible way of using your software.

Now, I'm not going to say that any of this is going to be easy to implement, completely aside from any technical challenge and nailing down those details, it's a bigger philosophical change for our community. And that's the much bigger issue. But the philosophical question about money is a discussion that we that we as a community need to have. What we've got at the moment is a tragedy of the commons. Everyone agrees that this software is good. Everyone knows the software needs to be maintained. But why should one individual company take on the economic burden of maintaining funding maintenance of a product when their competitors are getting the benefits for free? For me, the key lesson from the music and movie industries from the last 20 years is that if you make it simple and seamless, make it easy to do the right thing, people will do the right thing. If you make it simple and seamless for a large company to swipe their credit card, get charged $100 a month for using all this open source software that they've been

using for free. They will. Yes, people are going to cheat. Don't worry about it. As long as cheating isn't easier than doing the right thing The biggest reason this isn't happening right now isn't that it is that it isn't obvious what the right thing is. I could donate to the DSF or the PSF, but it's fiddly to organize and it's not clear where the money goes. And I can sign up to a few Patreons or sign up to a Bug Bounty program, but not everybody's there, and I don't really want the the the amount that's being given out isn't really enough to fund a real living, and I don't just want to contribute beer money. So what are we going to do? Short answer is I don't know. There probably isn't going to be a silver bullet. I'd like to think that monetizing a monetization channel on PyPI would work, but I'll be the first person to admit that that might not be the answer, although there might be problems I haven't foreseen. But I firmly believe this conversation is a conversation we have to have.

Free software as a movement is over 30 years old. Open source is almost 20. We've conquered the technical hurdles. We've even conquered the policy hurdles. Now it's time to tackle how we make this a long-term sustainable industry, not just a commercial set of commercial interests exploiting the naivety of a stream of dough-eyed volunteers. Now, I'm actually going to take a slightly more controversial position now and not take questions at this point for two reasons. Firstly, because this sort of talk is a magnet for I have a comment, not a question, questions. But also because this is in a subject where I have the answers. This is a discussion we need to have as a community, and I'm really eager to have that discussion Just not on this stage. We're about to break for uh for um for for afternoon tea. Please come and see me. I'm more than happy to cover talk about this at length And as always, getting me to stop talking at length is often the problem.

So thank you all very much.