Users need open source projects, but open source projects do not need users.

That asymmetry is, I believe, at the crux of the open source sustainability problem. We all use open source projects either directly or indirectly. But projects do not need us. Of course, projects need users to create rich and active communities, collaborate on code, and contribute in other ways; but those are optional components, and projects can absolutely do what they want in a vacuum, ignore their users, or even abandon them altogether. Ultimately, project developers do not need users in order to write code and put it on the Internet.

With the recent revival of the discussion about sustaining open source spurred on by multiple severe CVEs in a popular logging library, and with so many hot takes clamoring for more funding—some calling on companies, others on maintainers—I wanted to write about the problem and its solutions more wholistically, as I have spent many years thinking about this from my own experience with both failing and succeeding… a perspective that I hope some of you will find helpful.

I develop the Caddy web server, and I rely on open source sponsorships for my living. To be part of a more secure and reliable Internet, have your employer sponsor me (mholt) on GitHub!

Open source work comes in different flavors. On one spectrum, it's either your hobby or your job. As a hobby, open source is less about funding and more about personal interest. Donations or sponsorships are nice encouragement to keep going, but the money isn't for the nights and weekends, it's for the warm fuzzies. It's a nice feeling to have your lunch paid for, or to receive a thank-you note with a donation. (I might add, too, that "warm fuzzies" do matter and are valid rewards in volunteer open source efforts. There's nothing wrong with inviting donations to stay motivated.) But your livelihood is sustained through a separate day job. Volunteer open source has given us the majority of all open source projects, including some fairly popular ones like restic and gogs.

As a job, open source can generally be sustained by two models:

• Serendipitous: Open source is your job, but not your income. Your livelihood is sustained by other means. For example, your salary comes from a company that sells other products or services to make payroll, but your job description happens to consist of doing open source.

• Reliance: Open source is your job and your income. As the primary source of revenue, it's how you pay the bills. Whether you work for a company or for yourself, the project(s) must be sustainable to the degree you rely upon it for income. If you lost the income from open source, you'd need to find other work.

Serendipitous open source is great; it's how we got nice things like Zstandard, VS Code, Android, and Go, but also makes up only a minority of financed projects. Reliant open source is the majority of financed projects by far, and has yielded projects like Homebrew, curl, OpenSSL, Vue.js, rclone, Caddy, and countless others.

Reliant developers pay their bills from free software. And therein lies the problem that is primarily what this article is about. If you're only serendipitously working on open source, you don't have the same pressures to survive as reliant developers, but we have another special role for you.

Serendipitous open sourcers are the proof: proof that companies will pay for open source development (even if being open source is just a coincidence or side-effect). You seldom hear complaints about quality of life with serendipitous open source projects. That's because that model works. Being paid to work on open source is the obvious solution to funding open source, and is often the crucial missing piece of the reliance model as well. The hard question is, if you're not paid by your company to work on open source, where does the money come from when the software is free? This seems futile, but there is hope.

Boundaries

When you hear rallying cries to fund open source, or complaints that open source maintainers are overburdened and under-thanked, it's usually due to the misapplication of healthy open source principles. With liberal licenses, open source projects grant a lot of freedom, and that means it's easy for the relationship between maintainers and users to form a toxic imbalance if they aren't both careful and vigilant. Just like healthy personal relationships, healthy open source relationships establish clear boundaries and exhibit mutual respect to succeed.

With proper boundaries, a healthier, more helpful community can be fostered; developers and maintainers won't be over-burdened, companies and other users still get what they need, and expectations and requirements are satisfied on both sides. Establishing boundaries does not have to conflict with the freedoms granted from liberal licenses. And crucially, boundaries can be established without switching licenses.

Too often, we often talk about what open source licenses grant the users. Instead, we should place equal emphasis on what open source licenses grant the developers.

The first thing to consider is that the developers count as users. That means you can use your own project commercially! Think about that. You also have rights to distribute and modify your software, and you don't have to do that for free. And if you're the owner of the project, you are exempt from any restrictive license terms such as stating changes, disclosing source, retaining copyright, or not using the trademark. (Why? Because you used your ownership rights to endow the project with a license in the first place. You own it, so you set the terms.)

However, there is a delicate accord here. Open source is not entitled to funding. Just because you produced something useful does not mean anyone owes you money, especially with a license that says "Permission is hereby granted, free of charge." Of course, money has its place—and it does have a place in open source—but there is no implied contract that the code you wrote has to be paid for.

The converse is true as well: companies are not entitled to open source projects. Let me explain this one as it can be misinterpreted. Yes, open source licenses literally give companies a "title" to use the project for their capitalist purposes for free. However, they are not entitled to expect the same things from open source software that they'd get from commercial products. Almost all OSS licenses come with significant caveats that companies should be aware of; for example in the Apache 2.0 license:

Licensor provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License.

And similarly in the MIT license:

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.

These sections should make companies nervous, because it means they need to assume full responsibility when relying on software in their multi-million-dollar business that was probably developed by a tired young parent or college student who didn't get enough sleep.

In fact, proprietary software licenses often come with terms like these too. But companies are willing to pay a premium for them anyway because they know that even though the vendor is legally protected, they have access to expertise and services that effectively act like a warranty.

When using open source software, companies must bring their own expertise to know that the software is right for their needs. And if they're not sure? They can pay for a consultation. A company must be prepared to not only file bugs, but fix them too. They must have the means and know-how to implement a feature. Why? Because open source software is "provided as-is." They are on their own unless they pay someone for what they need. The risks of faulting here may be catastrophic to otherwise-successful businesses.

Healthy boundaries for a company might be:

• We do not allow open source software to inhibit our business by investing in:
  • a proper assessment of a project to ensure it meets our needs.
  • expert consultation or relevant hiring to integrate the software.
  • adequate support services.
  • ongoing development and maintenance of the software.
• We own our requirements, standards, or practices and do not impose them onto open source maintainers or developers—even implicitly.
• We examine our dependency tree for subtly crucial components that may be underfunded or unmaintained, and either invest in them or change our stack.
• If open source software is crucial to our business or is used in a critical environment, we strive to establish a relationship with the developers so they can be aware of the important use case. We do not assume they will cater to our use case simply because it is an important one. We offer to support them so they can support us.
• We either don't use projects that don't meet our requirements, or we invest in it to meet specification.

As you can see, boundaries are about asserting who owns and controls the business, and what companies will allow to happen to their business. A healthy boundary doesn't allow the blights of volunteer projects to negatively impact their business, nor does it take without giving. Standing by these boundaries may require virtuous and stubborn employees at multiple levels within the company. I urge you to be one of them.

Healthy boundaries for maintainers and project owners might be:

• I'm doing this project for me.
• I don't implement features or incorporate changes I don't want.
• I reject changes that I think are not a good fit for the project.
• Donations are not contractual.
• I only help when I can or want to.
• There's no hurry for me to get around to issues or PRs.
• Users can help each other; I don't have to do it all.
• I only give help privately if I'm being paid or sponsored.
• I don't accept donations or sponsorships.
  • To avoid feeling pressure (it's normal to feel pressure even if it's not warranted)
  • Or any other reason! (or no reason at all; it's okay)

As I learned from unpopular decisions with the Caddy project, hundreds of voices in a single day can feel very heavy. These kinds of boundaries can help prevent being steamrolled by user demands. Stick by them.

Here's an example of a boundary I set as the Caddy project grew: I decided that I could not afford to provide support in private channels for free. We have a forum where people can request help, but I am not obligated to respond to help requests there; because it's a public forum, I leave that mainly up to the community and chime in when I am able. If someone emails me with questions, my general rule is to send them my sponsorship plans and consulting rates along with a link to the forum if they prefer to have volunteers to help them instead. In my experience, people have respected this boundary and I've formed some good relationships this way.

Without boundaries, companies may use an open source project extensively with requirements that the project is not suited for, demand a and have expectations that the maintainers will not or cannot meet; their technical stack suffers, morale takes a toll as employees overwork in frustration, and costs increase as deployments break. Meanwhile, maintainers might as well just ignore these companies or abandon the project completely; after all, they don't owe them anything or have anything to lose. (I almost did this with Caddy back in 2017.) The relationship between developers and users becomes toxic, and the result can be virtually catastrophic (think widespread CVEs).

But with proper boundaries around the use of open source, companies can avoid frustrated employees, dissatisfied customers, financial and competitive losses, and technical debt. Reliant maintainers can provide quality software, cover their living expenses or make a profit, and avoid burnout.

This kind of healthy relationship solves the asymmetry of open source: users support the maintainers, and maintainers support the users.

Money

Many people view funding open source as a moral or ethical problem at its core: essentially, companies should pay for what they use (if a project accepts payment) because not doing so is exploitation. I sympathize with this perspective, but I believe a more helpful one is of economics and incentives, because we can reason about money more objectively and constructively this way.

When reliant open source developers want to make money, it must come from somewhere: an audience or market. Broadly speaking, the audience or market for open source products falls into two categories: consumers and businesses. (Sometimes investors, but… very rarely.)

On the consumer side, open source is inherently for enthusiasts; average consumers don't know or care what open source is, and they won't know how to use open source projects. Few open source projects are so nicely packaged and distributed that they are accessible to average consumers. You'd need to invest an exhausting amount of time packaging and polishing your project to make it accessible to less-technical consumers, and don't expect to get compensated for it. Open source also implies self-hosted, which consumers have no interest in: by far, only enthusiasts set up their own systems. If open source is your job, then you'll need to reach thousands, even tens of thousands of consumers to keep it sustainable, due to what consumers are used to paying. Think of streaming services, software licenses, or Patreons; they're often a few dollars a month. (I encourage you to be bold with your pricing, but also be mindful of your audience's expectations, especially when the software is fundamentally free. I once ran a personal backup service for $5/mo. and many customers cancelled because they said it was too expensive.)

Marketing open source projects to consumers can be done, but you will have to expend a lot of time and diligence to make it appealing for them, and expand your user base to make it worthwhile to you—so much so that you may need as much experience in business and marketing as in coding. Think email and social media campaigns, sneak peeks, exclusive beta invites, and anything else you can do to generate hype and spread like wildfire among our less-technical friends.

So in practice, targeting enthusiasts narrows your market and may be more profitable to you.

On the business side, I think there is much less diversity in what you need to plan for. First, in stark contrast to the average consumer, companies expect to pay money for anything they need. Oh yes, they will definitely be happy to use your free software free of charge. But this is your opportunity, because companies do have money and are in the business of spending it to support their enterprise.

When a business commits to integrate / invest in / use a particular technology, that decision does not come lightly, and they're usually in it for the long haul. Most businesses will not sign up one month and cancel the next, whereas I have seen consumers do this frequently.

Company size matters more than how heavily the company is utilizing your project. Large companies tend to not care about the significance of your project, as long as they get what they need. Once a team decides to use your software, their product manager or similar team lead should be looking for ways to enforce the boundaries we talked about earlier: how can we ensure this software is reliable, who can we talk to if there's a problem, what guarantees do we have, etc? The list goes on, and because they have deadlines they will expect to talk to somebody to answer these questions within a few days. Do all you can to answer their questions completely and helpfully, for this may be the final gate before they lock your project in. Once they do, they will be ready to pay you… after it clears legal.

Ah yes, legal departments can slow down the process, and even impose requirements that may seem unattainable to you (for example, having liability insurance). Remember: whatever requirements they impose, you can either negotiate them or simply charge sufficient to cover your cost of their requirements. I always charge extra for custom agreements including NDAs or proprietary licenses (I typically offer a significant discount if the code I write for them can be open source).

The art of negotiating with companies, having liability insurance, and dealing with other legal/paperwork concerns that enterprises especially care about, was overwhelming to me at first. It's one of the primary reasons I agreed to partner with Ardan Labs for Caddy work for enterprise clients. They have a well-oiled machine for handling enterprise paperwork, and I focus on the technical aspect. It's useful, and I recommend this approach if you want to support enterprise clients without dealing with the legal hassles directly. Of course, they take a cut, but at enterprise price points it should be worth it. Remember: the customer pays for their costs, not you.

Smaller companies are usually much easier to work with in the legal sense but may also have smaller budgets. Don't lowball your prices, though. If they are bootstrapped, then yes, you won't be able to exact much, but it's OK to adjust your offering to match what they can afford. If they have outside investors, they likely have a fair amount of funding, so simply undercutting your own rates does both you and them a disservice. Underpricing yourself sends a confusing and unsettling messages to companies who are looking to invest. Companies have compelling legal and tax incentives to spend money, so give them a chance to do that! If it turns out your prices are too high for a company, you can negotiate them into a price point they can manage if you want to; you might have to adjust your offering accordingly to avoid overselling, burnout, and other problems that can arise from lowering your prices. Simply offer less.

Now you may be wondering, but what do they pay for? Fair question, and we will answer that in the next section. Before we get to that, though, we need to address hobby projects, or projects that neither seek nor accept payments. This is because, as we have discussed above, the imbalance in open source is caused when one side does not maintain proper boundaries. For companies, those boundaries often involve paying money. For hobby projects, their boundaries often involve not accepting money. These are not compatible. And that's the hard truth: if a company is not able to pay money for something they need from an open source project, they must take care of it themselves and accept full responsibility for its selection, use, deployment, and any security and privacy bugs, financial losses, etc. Or maybe they pay someone else who has expertise with the project yet is independent of it to get what they need. But the point is, aimlessly using volunteer-only projects in commercial applications is precisely what causes asymmetry in open source. And when something goes wrong (think Heartbleed and log4shell), people clamor to "fix open source funding" when really, money isn't the solution at all. It's boundaries.

This is a good time to mention that there are a lot of problems money cannot fix. Money is a tool or resource we can utilize like water and electricity. Yes, we could repurpose the trillions of dollars spent on war for eliminating poverty… assuming money alone could solve poverty, which is such a diabolically complex issue (as it is closely tied to the conditions of our hearts, families, and societies) that simply distributing wealth will not likely result in lasting change. Similarly, pouring money into open source will not fix the asymmetry unless the money is properly utilized as part of a more integrated solution. The fundamental premise of OSS is, "Here, I made this, and you can use it and contribute to it if you want to; good luck." And so we need companies to be responsible for their software choices. In open source, companies are the entities with financial means, so it's on them -- not the hobbyist authors -- to invest in the quality and maintenance of the code.

The reverse is true, too: maintainers seeking to finance their open source projects must go beyond money by making themselves payable to their users. Filippo Valsorda calls this quality legibility:

Maintainers need to be legible to the big company department that approves and processes those invoices. Think about it: no company pays their law firm on Patreon.

To be legible, you will need to get formally established. Make it easy for your market to pay you. Maybe that is a Patreon, or GitHub Sponsors, but it might also be sending invoices and dealing with a legal department. Or a little of everything.

Now let's talk about some ways to go about doing all of this.

Implementation

What can you charge money for in open source? Here are a few ideas:

• Sponsorships
• Merchandise
• Private support
• Consultations, onboarding, and training
• Presenting at events
• Custom development work
• Prioritized bug reports / feature requests
• Guaranteed response times
• Publicity (tweets, case study page, link on website, etc.)
• Hosted version
• To simply keep doing what you're doing: maintenance and development!

Filippo suggests yet other possibilities, and I'll copy a few here:

• Best security practices
• Guarantees related to new releases, response times, and contribution activity
• Quality standards
• Maintainership succession plans
• Careful "supply chain" handling (dependencies, etc.)

I'd like to expound on a few of these ideas.

Merchandise

This can take a lot of time, up front investment, and extra work on top of your usual coding job. But it's fun, and people like swag. It can help add legitimacy to your project from the consumers' point of view. Businesses don't care as much about shirts and stickers.

Private support

If you want to finance your project, never ever give help in private for free. Even if it's in a public forum, you could set a boundary that you'll only help individuals in a public venue and require that companies pay for support. I have thought about doing this but don't personally find it necessary in my case.

To clarify, you should answer a company's questions that will help them commit to your project in the first place. You want that barrier to be low, and you want to earn their trust and build their confidence. But you don't have to troubleshoot their installation free of charge, either.

Presentations

Speaking at events can be a fun and scary experience if you're new to it. Some people find value in conferences, others don't. It's totally up to you. It definitely adds credibility to your project, especially if you are invited. If you are invited to speak, always ask for the conference to cover your travel and lodging expenses at least. Some conferences pay their speakers, others don't. If you're giving a keynote, charge for that. People are paying them to come hear you speak: you are the world expert on your project, after all.

Hosted version

We talked about how open source is inherently self-hosted by default. Some individuals, professionals, and companies will pay a pretty penny if you take care of hosting a private or custom installation for them. This may only apply to more "application" type projects rather than libraries, but consider this for your repertoire.

Custom development work

You might have to be careful with this one, because writing code for a company can detract from the health of your open source project. You have to decide how important the community aspect of the project is to you. Sometimes communities can carry on while you're busy with client work. Or, projects start to take the shape of your client's requirements, rather than what you envisioned. But in my experience, client requests tend to improve the project rather than hurt it, so I welcome that. You could always maintain a fork for them instead.

Companies will pay handsomely for expert development work, but I've also had clients who want the work to be open sourced, even live-streamed. (I offer a significant discount if the results can be open sourced.) That way it contributes to the project rather than detracts from it. Proprietary code is more valuable to companies than you think. Make sure your price acknowledges that.

Don't charge a simple hourly rate, as tracking hours is probably the last thing you want to be doing. The company that's hiring you probably doesn't care either. Besides, what if the code you write over ~12 hours on a weekend enables $100,000s of revenue annually for your customer? This has happened to me, and it's miserable to earn only a month's rent for that kind of value, especially considering the pressure to get it right and help them maintain it. After learning what companies pay for custom features they need, I should have charged more.

Do your best to give a general timeframe if they require one, but anticipate setbacks. I always try to overestimate how long it will take and then surprise them by delivering early. Thus, I give the project an overall cost, or if I have to break it down by time, I use weeks, not hours.

Things to watch out for where you can charge a premium:

• NDAs
• Non-compete (if even legal)
• Copyright assignment
• Automated tests
• Requirement changes
• Rushed delivery
• Proprietary licenses
• Insurance
• Custom terms
• Ongoing maintenance
• Dependency / supply chain management
• Code audits
• On-call (do not sell this cheaply)
• Guaranteed response times
• Integration/installation assistance
• Hosted version
• … to name a few.

Sponsorships

Let's spend some time on this one. I think sponsorships are the best product your open source project can offer. They generalize well and stand on their own as tangible products. Sponsorships are great because you can keep doing what you need to do to keep the project maintained and growing. Companies and individuals alike will pay for the assurance that the project will continue being maintained. That alone has immense value.

Despite the GitHub nomenclature, I do not consider one-time payments to be sponsorships; those are donations (unless the one-time payment happens to extend through the lifetime of the project or event, as is the case with conference sponsors -- but that is almost never the case with open source). For long-term full-time sustainability, I do not recommend one-time payments. You will either need to accept only large investments or continually attract thousands of one-time donors to achieve sustainability. Focus on subscriptions.

You'll need a service that can process payments or manage the subscriptions for you. I find GitHub Sponsors useful because GitHub is already on a lot of companies' approved vendors lists, or even already in their accounting system. In other words, expensing something to GitHub is a no-brainer for most tech companies. Whereas expensing something to a generic collective like Patreon or Bountysource is hell. Before GitHub Sponsors, I've had customers ask me if I can bill them through AWS precisely so they could avoid the rigamarole of adding a new vendor. (Spoiler alert: I couldn't figure it out and lost the sale.) Stick with big name services and try to avoid ones that add fees. GitHub Sponsors is a great option with zero fees (except Stripe's credit card fees, which are unavoidable.)

Some companies will need to be sent an invoice to be billed. That might be every month, every quarter, or every year. You should make it clear whether you support this option. To do this you may need to establish a business entity (it's easy to form an LLC in the US) with a bank account, and accept wire transfers and/or ACH deposits. I offer this option, but not for low-end sponsorships.

You have a lot of flexibility with sponsorships. I recommend setting tiers because this demonstrates that you own your product line. Businesses will take that seriously. They don't want to have to decide how much to pay you, just tell them. You may choose to offer perks with each tier. That's optional, but it definitely makes higher tiers more compelling.

Oh, right -- let's talk about price points. This is huge, and it's one of the biggest disappointments I see with nearly every open source project because too many are too low. It's fine to set lower prices if you accept sponsorships merely for motivation to continue your hobby, but if you are actually trying to sustain the project, you cannot go low. I see too many monthly $1, $5, and $10 tiers, with maximums of $20, $50, or maybe $100. This will not do. Companies will not take you seriously.

Although both individuals and companies can buy sponsorships from you, what companies are willing and able to pay should blow individuals' budgets out of the water, to the point that the consumer tiers are really not necessary. Individuals may pay a few dollars a month to support a project they like, but companies forgot how to count that low. You'll probably want tiers that appeal to small, bootstrapped startups which are excited to use your technology, as well as tiers that can cover enterprise requirements. You don't need to sell hundreds of them if your tiers are priced boldly enough to cover your costs. Just a few will do, and it's easier to maintain relationships with them then, too.

While sponsorship tiers stand on their own as tangible products, you might make them more compelling by offering perks. Perks should align with their price. Let's examine a couple ways for reasoning about this.

For sponsorship tiers that offer private support including answering emails or taking calls, compare those prices to consultancy fees. Consulting an expert should easily cost from $150-500 per hour. (This varies by many factors, including where you are in the world.) Consulting or contracting jobs are usually less secure forms of income: they have variable frequency and duration, and often carry extra risk or liability; hence the higher rates versus being a salaried employee. These rates cause sticker shock for smaller companies (startups) and I have had to turn down a number of requests because I am too expensive. Larger companies can afford these rates, but their legal processes can be slow and expensive, making consulting or contracting a tedious business.

Open source sponsorships have a unique opportunity here. Sponsorships are usually invoiced monthly, quarterly, or yearly; so what does your $10/mo. tier provide? If it's more than 4 minutes of your dedicated time for the whole month, you're not charging enough; not even close. What about a $25/mo. tier? Ok, maybe 10 minutes. That might be enough to answer an email with your expertise once in a while. If companies will pay a consultant $1000 for a day of work, can the developer of an open source project charge $1000 per month for about one day of their time every month? Few companies would justify it when framed that way, and you can see how a regularly-recurring fee doesn't translate perfectly well to an occasional service. So try to avoid giving time promises.

Even if we discard the time element, a lot of large companies won't even look at price points with just 2 or even 3 digits; don't expect them to take you seriously, especially if they'd be billed by an "open collective" like we talked about earlier. However, companies will readily pay a $1k/mo sponsorship with a support offering instead of paying an in-house developer $180k/year, especially as the sponsorship has other benefits.

If we think of open source sponsorships more like insurance, sponsorships become a very appealing option. Pay a small monthly premium, and occasional preventative care is covered. Have a basic question about how to best use the program in your infrastructure? No problem, for $25/mo. the occasional email like that is covered.

The exact price point and how much that covers is up to you. For comparison, US dental insurance premiums may be around $40/mo. and cover only two cleanings as preventative work every year. Without insurance those visits might cost about $500 total, which is nearly the same as premiums for the year. While dental and software are different markets, we can learn that even consumers are willing to pay a nontrivial monthly premium for basic care that is given only twice per year without significant discount. But they do this because dental insurance also provides discounts or benefits when more extensive work is needed, so there is often incentive to pay the premium over just paying out-of-pocket for preventative services.

Open source sponsorships can do something similar. Higher tiers can cover or discount more time-intensive requests. Want your feature prioritized? That's covered at a higher tier. Need a new feature added or an urgent bug fixed? A high-tier sponsorship can give you a discount on major development work, and since you're already on their Accounts Payable for the sponsorship, getting started on that can be very quick and easy. Sponsorships reduce the friction needed to get started on more urgent and extensive work, which is attractive to companies.

When seeking sponsorships, do your best to help your project spread and make sure people know when it's popular. Get it into as many systems as possible. Earn "street cred." Minimize the number of reasons why potential users or companies may turn away. Hint: an obscure or contentious license can be an instant dealbreaker.

Choose a standard open source license whenever possible. The legal structures and processes within large companies are set up to allow them more easily. You can use this to your advantage by getting your project into as many systems as possible. The more embedded, utilized, and depended upon your project is, the more potential you have for leveraging the project to sustain itself. Use "copyleft" (GPL/AGPL) only if you want to sell proprietary licenses to companies; otherwise they will not use your software, period. That's a valid strategy, but I have found more success in having my software spread "everywhere" first, then leveraging that to sell sponsorships. Sponsorships don't sell well in a vacuum: they need a network, a community. That also implies fostering a community around the project, which also takes time.

Some sponsors will want to develop an active relationship, but you'll find that the vast majority just want you to keep doing what you're doing and won't ask anything special. I've found that most sponsors don't even take advantage of the perks available to them. That's OK, as it makes me more productive, which is what they want.

It may take years of tuning for you to settle on sponsorship offerings that work for you and your market. That's OK! Remember, the main idea here is to own your sponsorship plans (rather than just accepting donations), and to make what you do offer compelling to your market (whether that be consumers, professionals, or businesses).

Thanks for reading. I hope to properly conclude this article when I have more time, as well as refine existing text according to experience and feedback.

If you thought this was helpful or awful, let me know! I'm @mholt6 on Twitter. You can also sponsor me on GitHub.