A Note About Sponsoring My LaSalle Software Open Source Serverless Projects
The idea of direct project sponsorship seemed very straightforward, until I considered it for my new open source serverless projecs.
I took a good look at what developers are doing with GitHub Sponsors, since I will be using GitHub Sponsors. Some of the things that are generally accepted practice made me nervous. Here are my notes about it.
Sponsorship is Strictly a Gift
To sway potential sponsors to select higher monied sponsorship tiers, developers offer inducements. This is a very common practice.
A popular inducement is listing names and/or logos on a project's web pages. Another popular inducement is monthly one-on-one calls. I have seen help with installation of the sponsored software, and help with customization of the sponsored software.
My reaction to seeing these inducements was to ask the question: what exactly is sponsorship? I
I scoured the GH Sponsors doc, and my internal dashboard, but to no avail. It seems to me that the definition of sponsorship remains with the developer, who does so in a tier's description. This lack of definition disturbs me.
Does offering consulting-ish inducements alter the nature of the sponsorship. Instead of supporting my open source projects with a gift where nothing is expected in return for giving money, these inducements make it where something is expected in return for giving money.
Do consulting-ish inducements turn a gift into a contract?
If consulting-ish inducements is, indeed, a contract for consulting engagement(s), then what are the parameters of these consulting arrangements?
The inducements that I see listed in higher monied sponsorship tiers seem to imply general and casual consulting engagements. The un-spoken message is that these are not "normal" client-consulting interactions. The consultant is not expected to know the client well enough to render opinions relevant to the client's situation. Rather, the developer is making their time available to the sponsor to answer general questions about the project. It is understood that the client is responsible for implementing things in their own environment.
It seems to me that installing sponsored software on a client's systems is a "hard" consulting engagement. A consultant is obligated to "know their client" to obtain sufficient knowledge to perform the installation. A consultant has the duty of "standard of care" as well. Frankly, the "installation" inducements in particular scare me greatly.
I have never seen any "fine print" for these inducements. Much is implied, and assumed. Which is fine in most cases. We are talking about anyone being able to sponsor, which is welcome for sponsorships. But the idea that strangers can simply click a button to consummate a legally binding consulting engagement scares me.
I have visions of this type of scenario: Someone tries something out that I mention in a one-on-one call, and as a result of their trying-something-out AWS dings them with a four figure surprise charge on their next invoice. AWS refuses to reverse the charge, so sponsor asks me to pay it. Based on something like: they relied upon my advice during a call where I was opining on their specific circumstances, within a client-consultant relationship consummated by consideration given in the sponsorship tier.
So for my two open source serverless projects, I am keeping the notion of sponsorship as a gift/donation explicitly clean and clear. There are no inducements whatsoever.
All Sponsors Are Equal
One thing I want to avoid is one or two sponsors contributing most of the money. Because, what is the probability that dominant sponsors will want the project to produce code for Bref and the Laravel Framework for their own projects -- or they withdrawal their sponsorships? Maybe not so much the DynamoDB project, but the Bref project I can definitely see the temptation.
The way I see it, for my two open source serverless projects, it is preferable not to have dominant sponsors, lest there be a patina of doubt of their benevolence.
When I initially contemplated seeking sponsorship, I thought the right way to proceed was to seek out a couple of corporate sponsorships. These sponsorships would provide legitimacy to attract individual Artisans to sponsor. I have since concluded that the preferred way to proceed is the opposite!
I have an innate sense that the general Artisan community should come together in the pursuit of open source knowledge in an area that has drawn little attention but has enormous potential.
I think that corporate sponsors will react favourably when they see grassroots support for these projects. As well, I am leaning towards the idea of having corporate sponsorships for my podcasts, as a way of supporting both my podcasts and these projects.
There is a Separate Sponsorship Tier For Meet-up Groups
After proclaiming that there is just one sponsorship tier, you will see two. One is strictly for devs in the meet-up groups that I organize, to support my meetup.com "organizer" subscription. It is completely separate from the open source project sponsorship.