As you may or may not be aware, a relatively recent development in my life has been the decision to start paying (in earnest) for the open-source software that I use. I've already explained my thoughts on why to sponsor open-source. I'm now going to explain, in detail, how I go about doing the actual sponsoring. (I'm using the present tense here, as I intend for my sponsorship efforts to be an ongoing endeavor.)

Cataloguing Candidates

The world of open-source software is vast. I only make use of a tiny sliver of what it has to offer. In order to determine all of my relevant sponsorship candidates, I do the following:

  • Manually catalogue all of the high-level tools and services that I consciously and knowingly enlist for my present-day software development efforts.
  • Install and run the npm thanks package against my codebases.
  • Run the npm fund command against my codebases.
  • Manually catalogue the tools and services that I use which aren't specific to my software development efforts. (Think Firefox, Have I Been Pwned?, etc.)
Given that I'm retired, all of my current software development activities and codebases are limited to personal projects. If I was still doing software development for a living, I imagine that I would factor in those activities and codebases made use of professionally, too. But, in those cases, I'd limit my scope to those tools and packages that I, myself, chose (or would have chosen) to use.

As a result of cataloguing everything, I've got my list of sponsorship candidates. In general, each entry in the list tends to fall in one of the following buckets:

  • Familiar (typically top-level) open-source packages
  • Unknown/unfamiliar (typically low-level) open-source authors and packages
  • Free and/or open-source tools
  • Free (typically closed-source) services and resources
  • Freemium tools and services

As you can see, my list goes beyond open-source to include other sorts of software. Anything that I'm not obligated to pay for, really. And that's fine by me.

Freemium

Many services that I use, especially for the purpose of running my blog, are offered on a freemium basis. Given the small footprint and audience of my blog, my usage of these services (currently) falls within the free tier thresholds. This includes Netlify, Heroku, AWS S3 & Cloudfront, Mailgun, Mailchimp, etc. The two primary development tools that I use, Sublime Text and Sublime Merge, offer free and unlimited trials. (With that being said, I maintain full licenses for each.)

Given that all of these services are commercial, revenue-generating enterprises, I don't feel any need to go beyond making honest and fair use of their free tiers. If I grow beyond the thresholds of their free tiers, I'll evaluate paying-up for a paid tier. Even if I never reach that point, if using them gives me a warm and fuzzy feeling, I won't hesitate to publicly recommend or endorse them (like I just did). In many instances, I'm guessing this is partially why a free tier is offered. So, win-win.

Open Source or Free

All of the unknown/unfamiliar authors and packages in my list are courtesy of the npm thanks package or npm fund command. Given the shared goal/purpose of both the package and the command, it doesn't come as any surprise that all of the candidates they spit out are sponsor-able. These dependencies present themselves for sponsorship in, generally, one of two forms:

  • as a project/team/organization
  • as an individual author/contributor

Regarding the projects/teams/organizations that are output, I'm typically familiar with a good number of them. They include Babel, 11ty, Parcel, etc. Conversely, most of the individual authors/contributors that are output, I'm less familiar with. (When going through this exercise the first time, pretty much all of them were completely unknown to me. It was only because of this effort that changed.) For each, I follow their sponsorship URL and read a bit of whatever they choose to write about themselves and why they are looking for funding. These write-ups go a long way in helping me "connect" with these authors and motivate me to fund their efforts - or not.

I suppose that, ideally, the software that they have crafted should speak for itself. However, some of these authors have built or contribute to dozens of packages, many of which are small, discrete, and low-level. As such, they are buried quite deep in my dependency tree, meaning that I've never heard of them. Given that, it helps to have the author call-out and summarize their body of work.

Everything not offered on a freemium basis or covered by the npm thanks package or npm fund command requires individual, manual investigation. This means visiting the dependency's web site and looking for an option for sponsorship. Excluding freemium services and tools, typically a good deal more than half of the dependencies that make it into my list are sponsorable. (Of course, with only a small percentage of my transitive dependencies choosing to make themselves known via the npm thanks package and/or npm fund command, that >50% hit rate is misleading.)

Picking Amounts

After completing this cataloguing and research effort, I take a stab at quantifying and loosely bucketing/ranking each sponsorship candidate. I then note a proposed funding amount for each and total up the amounts. I tend to have a ballpark total dollar amount in mind. If my total comes in a bit below or above this, I increase or decrease my proposed amounts here and there for some candidates until I arrive at a total that feels right to me.

As you would expect, "feels right" is completely subjective based on the current state of my finances. It also depends on whatever other altruistic causes are competing for my dollars at the time.

Given that one person's "generous" is another person's "cheap", I'm going to refrain from revealing any specific amounts here.

Making Payments

At this point, it's time to make the actual payments. Ideally, what I want is to make a one-time contribution to each candidate in an amount of my choosing, with my minimum being... a certain amount. 😃 Unfortunately, all too frequently, the sponsorship choices (restrictions) made by each author/project do not support this, or make it difficult to achieve. These restrictions include:

  • Only allowing for ongoing/monthly sponsorships, albeit with multiple tiers (fixed price points) to choose from.
  • Allowing for a one-time payment option, but without an ability to customize the amount.
  • Making a Tidelift subscription (which currently starts at $1,500/month) the only option.
  • Only allowing for donations in the form of a fixed-price annual membership.
  • Setting a minimum payment amount that greatly exceeds my budget.

The ongoing/monthly sponsorship restriction is the one I encounter most often. Fortunately, this can be worked-around. I'll initiate a monthly sponsorship, which I then cancel after the first payment. But, I consider this to be a distasteful hack. (If someone can explain to me why authors put this restriction in place, I'd love to hear it.)

To be fair, many of the ongoing/monthly sponsorships offer a $1/month tier (price point). And for many candidates, to me, that's an acceptable minimum. But, I don't want to see credit card fees gobble up any more of my donations than necessary. In that light, making a one-time (annual) payment of $12 would seem to be more advantageous to both giver and receiver than making twelve payments of $1. But, then I hit the issue of my desired one-time amount not matching any of the available tier amounts. So, I'm left to round up or down by a buck or two.

Fortunately, Patreon will allow you to edit your payment amount (upward only) after you select a tier and arrive at the payment page. GitHub Sponsors, on the other hand, does not provide such an option.

Whenever I see an author/project choose Open Collective as their sponsorship platform, I smile inside. Every collective I've seen offers a custom one-time or recurring (monthly or annual) contribution option, with $1 always being the minimum amount. I'm not surprised to see this being the most popular contribution option on every collective I've seen.

Regardless of the platform, I make my payments in whatever allocations make sense to me. If I'm "forced" into any monthly sponsorship options, I'll set a reminder to myself to cancel them in a month or so.

Done. Right?

Well, for me, no.

Giving Thanks

After making all of my payments, I'm still not finished. Remember, only a little more than 50% of my dependencies tend to be sponsorable. What of the rest? For me, I consider these dependencies to be "thankable". After all, money isn't everything.

Me being the thorough chap that I am, I did some research to understand the best way to go about giving those thanks. On HackerNews, I found one discussion about thanking open source developers, and then a second discussion. Those discussions led me to a third discussion on Reddit.

As you would most likely expect, there isn't universal agreement on how best to thank open source developers (who don't make themselves sponsorable). But, I was able to draw the following conclusions:

  • For all dependencies, regardless of size or popularity, upvote/star it and maybe follow it (where possible). Publish a review of the dependency that will help others find and use it. In short, throw some publicity the dependency's way. Absent any thanks or money, if nothing else, a dependency wants to be utilized.
  • For smaller, less popular dependencies, send a customized message of genuine thanks, with no strings attached or request of anything in return. Personalize the message with details about how you came across the dependency, how you are using it, and how it benefits you (e.g., saves you time or makes something possible that otherwise would not be feasible). Mention the specific dependencies by name so that the author (if they are associated with many) can gauge what to spend future effort on (if they so choose). It should be obvious to the recipient that you put time and effort into your message. (Many authors don't care for feedback that requires no effort.) However, keep in mind that while larger, more popular dependencies may also appreciate such messages, you run the risk of simply "adding to the flood" (of issues, emails, chatter, etc.) that they deal with everyday.
  • For a few authors, no amount of publicity or thanks garners more/adequate appreciation than contributions back to their project. This can be in the form of code, documentation, testing, etc.

This sounded good to me (the first two points, at least) and is what I decided to do.

Regarding the final point that work contributions are the only adequate form of thanks, I just don't see it. While I can appreciate the spirit of this desire, I find it to be too extreme. After all, one of the great benefits of open source is the boost to productivity that comes from building on top of ready-to-use dependencies. Much/most of that boost would be lost if everyone felt obligated to obtain a level of familiarity with each of their upstream dependencies that allowed them to make meaningful contributions back to those dependencies.

Who to Thank

For the customized message, this starts with figuring out who to thank. For most open-source software, the project's public code repository is the best place to start. Almost all of those repositories are hosted on GitHub.

OK, so you're looking at a code repository - now what? Exactly who do you thank? The repository owner? The maintainer(s)? All of the (possibly dozens of) contributors? How do you differentiate between a contributor and a maintainer? What if the repository owner is an organization with multiple members?

For its part, GitHub supports usage of a CODEOWNERS file, which is meant to "define individuals or teams that are responsible for code in a repository." However, I've never/rarely seen this file in the repositories where I've looked.

For each repository, I examine the list of contributors. Don't assume that the owner of the repository is the primary (or the only primary) contributor. On GitHub, the UI pairs each contributor with a graph that visually conveys their commits to the repository, plotted chronologically. Based on what I've seen, it's typically the case that one or two contributors account for the lion's share of (frequently recent) commit activity. I think it's fine to zero in on these contributors for thanking.

From there, I click-through to each contributor's user profile to find available channels of communication. My preference is email, but a direct message via Twitter is fine, too. Sometimes, no channel of communication is provided, but a URL for a personal web site is. In that case, I go digging. Only rarely will I come up completely empty-handed. If that's the case, oh well. They don't want to be contacted or thanked - and I move along.

But, what about dependencies with multiple (sub-)repositories and a multitude of core contributors? Do you write eight (as an extreme example) individual messages? I suppose I could. There's no law or convention that says not to. But, oof. Fortunately, most every project I've seen with this sort of participation/structure has an Open Collective. This is another way in which Open Collective shines, as it makes it easy to determine who the owners and core contributors are, complete with names and a form for contacting the collective/project as a whole.

I also have a number of dependencies that are free, but not open-source. These include services and other resources that make no payment options available. As you would expect, these dependencies do not have public code repositories or lists of contributors to refer to. Ownership of these entities is typically anonymous, with only a catch-all email address, contact form, and/or Twitter account available for communicating. But, that's fine. In these cases, I simply address my message to the "[dependency name] team".

What to Write

Now that you've figured out who to thank and how to send that thanks, what do you write? In my messages, I try to briefly summarize how I've made use of the recipient's software (i.e., building my blog or simply developing software, in general), mention anything I really enjoy about what they've built, explain why I'm thanking them, and provide a pointer to this article (and/or the preceding "why to sponsor" article). While I re-use various snippets and phrases between messages, I definitely craft each message individually so as to be as personalized as feasible.

Writing these messages definitely takes time. There's no getting around it. Much more time than sending money. But, that's sort of the point. A sentiment of thanks that requires almost no time or effort possesses very little significance or meaning. True appreciation can only be optimized so much.

OK, so money has been sent and so have messages of thanks. Done. Right?

Wellll, not quite yet.

Thanking After Paying

What of my sponsorable dependencies? Just because a dependency makes themselves sponsorable doesn't necessarily mean that they wouldn't appreciate a note of thanks. The two aren't mutually exclusive.

In general, there's nothing preventing you or I from taking both actions for any sponsorable dependency. But, those actions have to be done separately, as none of the payment options/platforms I have come across allow for accompanying a payment with anything longer than a terse note.

Beyond that, one additional complication that you soon encounter is how to go about customizing your message of thanks to such dependencies. After all, a large number of sponsorable dependencies are surfaced via usage of the npm thanks package and/or npm fund command.

In my case (and I venture to say yours), most of these dependencies tend to be low-level and transitive. If it wasn't for me going through this exercise, I would never be (individually) aware of them. As such, there's no compelling story I can share behind my usage of those dependencies. The decision to use them wasn't mine. I'm not aware of how or why they were chosen. In fact, I find it disingenuous for me to even upvote/star such dependencies. I'm simply glad that they exist, because they helped a dependency that I did actively choose come into existence.

In lieu of those details, I still thank. I look for the dependency in my dependency tree, make note of which "recognizable" dependency relies on it (if any), and mention that in my message. In my message, I'm up-front and transparent with the fact that I found them via usage of npm thanks and/or npm fund. I figure that even someone who is responsible for such a "building block" dependency would like to know how their work ends up being used (maybe even more so than for a top-level dependency).

However, on my first go with this exercise, as I dug a little deeper into the list of dependencies output by the npm thanks package, I realized that it would frequently attribute packages to authors who weren't found in the list of contributors for those packages. I believe this is because the npm thanks package generates its output based on the list of maintainers found for each package via the npm registry, which does not necessarily correlate with the list of contributors found in the package's repository.

Curiously, the list of maintainers for these low-level packages can be very long. It kinda' seems like many of the individuals listed in there are simply there by virtue of them being one of the cognoscenti of the (Node.js) open-source software world. I don't claim to understand how that works, but I choose to trust that the results are accurate and inclusions are warranted.

Tools that Help

For this effort, I find howfat and NPMGraph to be useful tools to diagram my codebase's dependencies. For me, Mr. Minimal, I prefer howfat. I can easily save the results to a text file and search through it. But, the visualization provided by NPMGraph will surely be more appealing to others.

Going Forward

Whereas I feel that repeating sponsorship payments to an overlapping cast of dependencies year after year makes sense, I think that repetitively sending messages of thanks (to already-thanked dependencies) on an annual basis is excessive. But, if a dependency were to stand the test of time (as a foundational part of my codebase) several years out, I can see myself thanking it again.

For those dependencies that grow near and dear to my heart, to the point that I feel I can make constructive contributions back to them, I will. As with the messages of thanks, it's the show of time and effort that serves as a true indicator of gratitude. In that sense, contributions back are the truest form of appreciation.

Closing

After a professional lifetime of thankless mooching, this is my plan of action. Paying, thanking, paying & thanking. It requires a significant commitment in terms of time and effort (and possibly money, depending on your choices), but I find it to be rewarding. Thoughts?