Monetisation—a topic that causes intense discussions in the german podcast community these days. Some groups resent the idea of advertising and are very vocal about it. But more and more podcasters try to make a living with the content they produce and are now contemplating their options.
I am not going to throw in my opinion on the topic here. However, I would like to discuss monetisation from my perspective: as an open source software developer. Listening to discussions at the Subscribe 7 conference recently made me realise the issues brought up are more similar than you’d first think. And just a few hours ago I stumbled upon an announcement by Alex Olma (iPhoneBlog.de) who started a paid membership, explaining his intentions with a quote that nails it:
We don’t make movies to make money, we make money to make more movies. — Walt Disney
(Many) podcasters don’t make podcasts to make money, they make money to make more and better podcasts.
I don’t work on the Publisher to make money, I make money to spend more time working on the Publisher.
Hobby podcasters can create and distribute content, even if they don’t earn a penny. The same applies to me: Even if I don’t earn anything with the Publisher, I will find time to continue working on it because I believe it is a valuable tool for efficient podcast publishing workflows, as well as providing an alternative to platform-lock-in, thereby being an instrument in the cause of keeping podcasting free and open.
When we first started asking for donations I was reserved towards the whole idea of making any money with my work on the Publisher, fearing it might affect development priorities. I must add, though, that I was a student then and money as a concept was in a whole different category compared to now.
The truth is this: the more money I make with the Publisher, the more time I can spend on making it better (with the ceiling of “making a living,” which would allow me to spend all my time working on it). The same applies to podcasters: the more money they make, the better their output will be. From buying quality equipment and renting a studio to being able to spend more time on pre- and post-production and hiring people.
There are many ways to make money with a WordPress plugin. I will discuss some and explain why I think each might be suitable for the Publisher or not.
A popular choice for plugin developers is to separate Free and Premium features of their plugins (example: CometCache). This can be a valid model but the line between free and paid features has to be drawn very carefully. There needs to be enough interesting stuff in the premium section to make a sell, but the free plugin must be usable on its own. Also, this approach always has side effects like nagging ads in the plugin asking you to upgrade and the development effort to build and maintain the paid-upgrades-infrastructure that might be better spent improving the actual plugin. For the Publisher I would be hard-pressed to pick features that go into a paid version because I would potentially lock out hobby podcasters who are already struggling to finance the required hardware to start a podcast. Also, I could only consider this for newly developed features since major parts of the Publisher are crowdfunded. Moving some of them in a paid version would not be very, uhm, honorable 
Similar arguments apply for paid add-ons (example: AwesomeSupport).
Many “premium plugins” come with premium support, which is what I am already doing. It’s great since it’s an additional service that doesn’t affect the plugin at all. Podcasters on a tight budget still get free support in our community forums but if you are looking for guaranteed responses or simply a direct support channel to me, paid Publisher Support is available. It’s also a good way to support the further development of the project. Since its start about a year ago I received an average of about 100€ per month (before taxes) through paid support packages. That’s a nice amount, but a far cry from “making a living”.
Then there is freelance work. I regularly help clients setup, maintain and improve their podcast sites. That’s more enjoyable for me than “miscellaneous WordPress jobs” but it rarely affects the Publisher. Time spent doing client work, even if it is Publisher related, is time spent not working on improving the Publisher.
With the advent of Slack, communities and memberships became the new thing that everyone seems to be doing (like nomadlist for digital nomads and Creative Class for freelancers). Create a Slack, add a paywall, and profit. This is sometimes mixed with access to educational content like video or audio tutorials. The general membership idea existed long before Slack, though. For example, the writer Shawn Blanc provides a twice-weekly, behind-the-scenes podcast for a $5/month membership. Matt Gemmell follows a similar idea by sending a weekly newsletter to paying members. Others, like Holger Klein, use Patreon to ask for regular contributions, sometimes without any incentive other than “support my work”—which makes sense, since fabricating an incentive, however useful it may be, means time not spent on the core product (a podcast for the podcaster, a book for the writer, or a software for the developer). And when I create educational content for the Publisher, I want it to be accessible to everyone for the most benefit.
Let’s get back to Slack for a minute. My first instinct when considering it is that we already have enough podcast related communities: the German sendegate.de for podcasting in general and community.podlove.org for “everything Podlove”. Segmenting communities might be a valid option when they get huge, but that’s not the case here. It has to be said, though, that a chat like Slack has a different communication dynamic than a forum. It might even be suited as an optional support-channel. Currently, support requests are answered with a ticket-based system. In my experience, there’s often some back-and-forth involved to get to the root of the problem. A chat might quicken the process. However, chat as a medium sets different expectations on response-times. While it’s accepted that a newly created ticket takes a few hours to respond; as a customer, when I am invited to a chat support channel, I expect a response within minutes—but since I’m the only one answering support requests, I can’t possibly guarantee that. To wrap up on communities for now: There’s some value in chat as a support-channel and there’s always a benefit to be had when people with common interests gather in the same spot. But it’s also yet another channel.
Crowdfunding played an important role in getting the Publisher to where it is today. However, it works best to kickstart and validate a concept, not to fund a continuous effort. An idea might be to fund specific new modules that seem interesting enough to draw a coin from your wallet. It’s tedious and time consuming, though, to plan, organise and execute a new campaign every few weeks. It also doesn’t compensate for the natural deterioration of software: would you fund a milestone that’s nothing but “Internal adjustments to clear technical debt and enhance maintainability”? I thought so. Money should not dictate what’s being worked on.
Which is why a Patronage might be better model at the moment. Technically, there is no difference between a donation to specific development-efforts and a patronage-related payment. But as I argued above, donations come easier when they are dedicated to a specific goal. Patronages seem better established as a means to keep projects going.
And finally, there are paid services. Separate related offerings to enhance the Podlove Publisher experience. File hosting comes to mind immediately, which is what Blubrry (PowerPress) is doing. Thinking one step further, it would even be possible to provide a complete “managed podcast site” experience including not just files but the whole WordPress setup. That would definitely be useful to many since it would allow to simplify the setup greatly. However, it would certainly suck up all my spare time for months, if not years. Time that I’d rather spend improving the actual software, rather than fabricating services that might earn money in the future. (Technical aside: being responsible for hosting WordPress would give me nightmares. Also, we’re only using WordPress/PHP because it runs on any hosting plan. If I’d work on anything hosted, my first action would be to wave PHP goodbye.)
To sum up, there’s no shortage of options to monetise open source software in general and the Publisher specifically. Right now I’m making a living on a combination of some of the options above, with freelancing contributing the most by far. As I’ve explained, I’d like to free up more of my time for work on the Publisher (or related projects) by becoming more independent of my freelancing income and earning more through any combination of the above—or any approaches I haven’t thought about yet.
Phew, this took a bit longer than expected Thanks for staying with me until here. If there’s anything on your mind right now, I’d be happy to read your thoughts.
This article first appeared in the “Publisher Weekly” Newsletter. Subscribe to get new articles delivered to your inbox.