Clarify guidelines even further #112
Comments
|
I don't think OpenSSH is the clearest example, because donations to OpenSSH go through the OpenBSD foundation 1. Perhaps we can give the example of donating directly to a solo maintainer? I think even donating to a group of maintainers without going through a foundation can have edge cases. For example, Hare has an Open Collective page. But the money doesn't go to maintainers — we save the money up to spend it on e.g. potentially paying someone to do a security audit at some point, though we have never spent any of the money so far. I think all of the above is probably a “Yes”, but it might be helpful to address it explicitly! Footnotes |
|
Copying a concern I raised on Discord to here:
We included wording like this in the CFG:
Also:
https://github.com/collective-funds/guidelines/blob/main/GUIDELINES.md |
|
I think 4. should be allowed, depending on how it was structured. I eg got funded by Platformatic to speed up the launch of |
|
I want to capture Astro here as well. They commercialize Open Source sponsorship by working with partners in a sort of "sponsor Astro" way (but Astro is a for-profit company who also builds Astro the Open Source framework). In this case, the open question is: If Astro contributes the requirements to open source projects within their ecosystem (but not part of their entity), does it qualify? I think the fact that Astro raises the money from others to invest in this may be irrelevent here. |
@voxpelli What would have happened if you hadn't sped up the launch of neostandard? What if you had taken a beach vacation instead? I imagine Platformatic would've asked for their money back. What if they had written you a paper check instead of transferring funds on OC? This looks to me like a contractor relationship, albeit a highly informal one. Strings are attached (right?). Doesn't count for Pledge. The only string allowable IMO should be non-exclusive logo placement. |
|
Money donated to any I think that's the key – one hire a contractor to deliver certain outcomes – then it's like any contractor job – but if one fund a maintainer to independently work on one or more projects, then that's still open source I think. It's the autonomy and independence that's key? Eg. an "artist in residence" kind of deal for maintainers should also be allowed? Even if one is fully funded by a company, as long as one retains one's autonomy? |
|
Ah, gotcha. I interpreted (4) as implying a specific scope of work. I think the case you describe is fine. As to artist-in-residence, I'd still bring in the distinction between contractor and employee. Former yes for Pledge, latter no. Contractor without a specific scope of work? Is that what we're saying? |
Yes 👍 As an employee one can never be truly independent |
|
Update: Astro is developing a hosting platform called Astro Studio that is currently in closed beta.
Hrm ... possibly, but hear me out ...
This to me looks way more like what I would expect a Python or a Django or a PHP Foundation to do: collect money via sponsorships (i.e., by companies like Sentry who are fulfilling the Pledge) and allocate that money within the ecosystem they are stewarding. There are three basic parties to Pledge: companies, platforms (TD, OC, GHS), and projects. Let's say we take The Astro Technology Company off the table because afaict it does not exist. Then Astro is just an Open Source project, and Open Source projects can't join the Pledge, they can only receive funds from companies that have joined the Pledge. Would that then make Sentry's payment to Astro a part of Sentry's Pledge fulfillment? Possibly yes (to be clear: in the past it has come out of a different budget), though Sentry gets exclusive placement as Astro's "Official Monitoring Partner," and above I just suggested that non-exclusive logo placement should be the line. Otoh, conferences put on by FOSS foundations regularly have exclusive or limited branding opportunities, so maybe I should drop the "non-exclusive" part. Yeah, I'm settling into the view that Astro is an Open Source project, and therefore is the wrong sort of entity to be talking about joining the Pledge. Astro is on the other side of the equation. I concluded in "The Future of FOSS Foundations" that foundations could evolve "to look like weird software companies." Astro looks like a company that could evolve into a weird foundation. I've previously observed Geomys as an example of a foundation presenting as a consulting company. I'm now seeing Astro as a related case. IMO Geomys and Astro should both be classed as projects vis-a-vis Pledge, not company members. |
Alright, I've now learned about Astro Studio (basically Astral is like a Vercel or Laravel where the framework is Open Source and they monetize with a PaaS). That means The Astro Technology Company is back on the table. :) In that case, Sentry's payment is to The Astro Technology Company as a business partnership (maybe there's a clarification here in terms of payments to single-vendor commercial Open Source, which is what Astro essentially is?), and Astro is running their ecosystem fund, and we're back to the original question of whether that counts for the Pledge. I think a related case that is clearly not Pledge-compliant is Sentry funding development of Sentry SDKs. There's no (or scant) value in a Sentry SDK apart from Sentry, we're pretty much exclusively aggrandizing ourselves by sponsoring SDK development. Are the recipients of the Astro fund things that have any meaning apart from Astro?
There is a mix. My feelings are mixed. 🤔 |
|
Hi! HeroDevs would love to join ASAP, but first we need to confirm if we qualify. Our business model is basically that we provide private forks of EOL OSS software with vulns patched. we then contribute a % of our revenue back to the maintainers. The only "strings" that are arguably attached are:
We directly support projects such as Bootstrap, Nuxt, Vue, and many others this way. We also are a member of many foundations: OpenJS, OpenSSF, LF, Drupal, to name a few - if these membership dues count. We will ofc be able to commit to an annual blog post citing at least $2K/dev (does this have to be at the end of every calendar year, btw? or could it be a year after joining? either way is fine, just need clarity) |
|
Hey, @ljharb! Thanks for reaching out! We would love to have HeroDevs on board! The foundation membership dues definitely count. 👍 On the EOL partnerships—are those exclusive or non-exclusive? Are projects required to only link to you as a commercial support option? |
|
As far as I'm aware they are all non-exclusive. If any turn out to be exclusive, we will omit those contributions from our report. |
|
Sounds like this counts to me, since there aren't really any strings attached! The way we currently have things set up is that members submit a report one calendar year after their previous report. |
|
Awesome! When is the first report due? |
|
If you could submit a PR as soon as possible that would be great, so that we can (1) go over any potential questions, and (2) make sure we get the art for the marketing campaign done on time. Let's continue this discussion in your PR once it's done, but feel free to DM if you have questions! |
|
→ #146 |
|
We had quite interesting discussions on today's Pledge steering group call and also on openjs-foundation/sustainability-collab-space#15 about the HeroDevs case. Does the revshare count towards Pledge? If so, does it count for HeroDevs, or for HeroDevs customers? I raised a similar question about Tidelift in #52, which I ended up closing out early with no-one else engaging as it was purely theoretical. There I was thinking about whether Tidelift payments should count for Tidelift customers, but I could imagine Tidelift asking if their payments count for them as well. For both HeroDevs and Tidelift it's part of the business model: customers pay for security assurances, some revenue passes on to maintainers. tl;dr is that on both calls we got pretty confused trying to reason about how to think about HeroDevs revshare when considered in the context of Tidelift as well as more traditional payment platforms (TD, OC, GHS, etc). So let's return to first principles: at heart Pledge is supposed to be about no-strings-attached cash payments from companies to Open Source maintainers / foundations / projects. We've already established on #132 that we're not trying to account for every possible way a company can support Open Source. There are more ways than Pledge and they're all great! I think that precedent should be our guide here as well:
|
|
I'm sorta back to thinking that the cleanest way to do this would be to specify exactly which foundations and platforms count for Pledge fulfillment.
It does still get iff-y around benefits ~= strings. For example:
🤔 |
|
I wanted to summarise the point I made on the call as this pertains to both HeroDevs and Tidelift. I don't think HeroDevs customers should be able to count their payments towards the Pledge. Say HeroDevs shares 20% of their profits with maintainers (I'm not sure what the number is). HeroDevs customers are paying HeroDevs for a service. The fact that some of that money goes to Open Source maintainers is a bonus, an extra selling point. Most probably, customers would still be paying HeroDevs even if that payment to maintainers did not happen. Importantly, the primary intent that HeroDevs customers have is to get their business needs met, not to give money to maintainers. This is very different to going through a platform like thanks.dev where you make payments with the express intent of them going to maintainers. This is especially true because the majority of the money goes to HeroDevs, not to maintainers. I admit that I don't understand Tidelift very well. But I think whether companies can count their Tidelift payments towards the pledge would also depend on this. If they give money to Tidelift with the primary intent of that money being distributed to maintainers, and the vast majority of that money is distributed to maintainers (minus the Tidelift fee), and Tidelift only offers a couple of tangential services as a bonus, then I think those payments should count. If not, probably not, in my opinion. tl;dr: In my opinion, for a company to count payments to maintainers through an intermediate platform towards the Pledge, it must be the case that:
|
|
The definition absolutely needs to be better defined, especially better explained so it's easy for companies to understand, and more accurate/consistent across the board. In particular, there are so many different ways that companies can fund things (i.e. outgoing cash, which is the point), different kinds of activities to fund, and different kinds of entities to fund (maintainers, foundations, other?). One need is to have a chart of all the major funding processors, and check yes/no/maybe for each one, because that will be a common question.
The other big question is: what's the relevant importance (in terms of how you present this listing) of direct payments without strings for code development on specific projects, versus everything else? Sponsorship payments made to 501(c)(3) or public charity foundations are a critical way that larger project ecosystem works, but they are primarily support services for their hosted code projects, not code development or maintenance. Should those payments count equally to direct maintainer cash? (I'd say yes, but it's up to your goals here). For 501(c)(3)s, I would not worry about benefits offered, like logo placements or event ticket discounts. Those are not (really) material values for the sponsor compared to the funding they're giving the foundation. Even the case of getting a booth at an event too - which is a marketing benefit for the sponsor - is also a real win for the foundation, because it gets more people and services at the event for their community. I've modeled the sponsor levels for many foundations if that helps: Note that 501(c)(6) Business League nonprofit foundations are a different beast, in terms of the typical direct benefits sponsors get, or the level of control over the underlying project the sponsor gets. It's certainly some benefit to the FOSS ecosystem; but it's not the same kind of scale or ratio of "freely given with no strings" benefit that public charities get. Hope that makes sense! |
I'm waffling. Now it feels like if we're definitely not counting HeroDevs revshare for HeroDevs customers, and that money is really as no-strings-attached as it seems to be, it ought to count for someone. It could help to distinguish between "selection criteria" and "strings attached." Only giving to projects that publish an EOL policy is a selection criteria, whereas something like priority bugfix access or roadmap influence would be strings attached. It seems like companies should be free to select which projects to sponsor based on whatever criteria they like, and even to make this known. If the payment carries an expectation of future work, I think that's where it would get into "strings attached" territory. |
|
With our current blog post that should go out shortly, based on prior confirmation, we're counting Foundation memberships, and GitHub Sponsors payments. I don't believe these are from contractual "rev share" agreements, so I assume they count for us, and not for any of our customers. I also agree that rev share numbers shouldn't be double counted, nor zero counted, as long as they don't compel maintainers to do anything more than put up a logo or a link, especially if it's non-exclusive. |
|
I’m wondering if contributing to an Open Collective fund (see the docs and blog post), which redistributes to multiple open-source projects, would qualify as part of the Open Source Pledge. For example, here are some funds that follow this model (some descriptions may be outdated or inaccurate):
This model simplifies the process for corporations while scaling contributions. Would contributions to these types of funds count toward the Pledge? |
|
It seems like they should count for contributors, but not also count as contributions for the Open Collective fund itself. |
In case of Tidelift I think it matches those apart from maybe the |
|
Another "nextgen" funding channel like Tidelift and HeroDevs are Polar.sh – maybe good to also bring them into the equation of platforms that to different degrees blur the lines of more traditional setups – they are like a mix between GitHub Sponsors and Patreon and names itself a "monetization platform" primarily, but eg. also provides issue bounties and straight up GitHub Sponsors / Open Collective style supporting (Only mention of them so far seems to be in #50) |
If the rev-share was like an affiliate program where the clicks was tracked and only given through that, then it should count as a payment rather than a donation I think, but in this case its "do we have customers that buy support for this specific project" independently of whether they came to HeroDevs through the links on the project website or not, which makes it different. Probably has to be judged from case to case whether a rev-share should be seen as payment or donation. |
|
We realistically want the limit the vehicles used to fund open source devs, because otherwise a lot of people are going to qualify and we're not going to see a change in the status quo. Rev share falls in the similar tricky bucket as some others, where ultimately its a marketing activity. In the same vein that you sponsoring a conference shouldn't count towards the goals, rev share often shouldn't. I think it'd be worth opening a ticket for the rev share conversational specifically. We've said we're going to revisit some of the funding vehicles post-launch, but we want to keep the core goals tight and easy to understand. |
|
That's correct. |
|
Following up on #112 (comment)
So the pledge would be in the form of a financial contribution to the Fund (see https://blog.opencollective.com/funds-for-open-source/). Those funds in turn would be allocated to projects the fund is supporting (by the fund administrators). Realizing most of the examples provided in #112 (comment) are confusing as most of those don't have financial contributions enabled but https://opencollective.com/fundoss/contribute is an example that does... ...of course the original purpose makes it a bit of an edge case (some related discussion in #89), but as an admin/owner we could potentially restructure so companies could contribute to open source ecosystems or focus areas (see FUNDOSS/fundoss#47 for context). FundOSS again is an edge case. Based on what some of the folks from Open Collective/Open Source Collective were saying on the ecosystem kickoff call, it seemed like there was agreement that contributions to a fund should count. Does that make sense? |
|
Hi!
Given that many foundations formally or informally prohibit paying maintainers to do maintenance work, and the majority are structured (in their bylaws!) as being explicitly pro-industry, rather than pro-maintainer, I'd strongly suggest a lot of scrutiny on payments to the average foundation. At the very least, restrict it to 501(c)3s and reject it for c(6)s. About Tidelift specifically:
That's definitely why we exist.
We don't disclose our percentages so to some extent you have to take our word for it. It's a lot, but not "the vast majority".
Really not sure how to answer this for us. Our customers get benefits (of additional information and tooling), so it's not a charitable "gift" for them. Also, in our opinion, it shouldn't be charitable: charity will just going to go away in the next downturn, so we want to clearly and firmly offer benefits and services that aren't just warm and fuzzy feelings. But our customers also very clearly want to pay upstream maintainers; our entire reason for existing is to do that. So at least their intention is very consistent with the goals of this project. I'm not sure how to weigh that in your shoes. 🤷🏽♂️ |
|
Yay! @tieguy! 😁 I don't have a slam dunk answer today on how to think about Tidelift payments vis-a-vis Pledge commitments. Let's let that particular question simmer while we get through our marketing launch next week. It'll be a sign of success and growth for the Pledge when we have Tidelift customers ready to join and asking about whether their TL subscription counts. Also a sign of success when Tidelift itself is ready to join and asking whether it's share w/ maintainers counts. 😌 |
|
I was reminded that the (c)3 (public benefit) v. c(6) ("trade association") distinction is very American. Explainer in general here; specific to our context here. Excerpt from that second, published by a (c)3 so it has an opinion but I think the factual summary below is reasonably accurate:
One could dive further into each org (eg, we're seeing this week that the Wordpress Foundation is a (c)3 but problematic nevertheless...; while PSF is a (c)3 that pays several very good maintainers to do important work) but that's at least a starting point. |
|
The way I would love to see Pledge evolve would be to have parallel accountability on both company (consumer) and foundation/project (producer) sides with first-class membership on both sides. We dropped time/code and gift-in-kind contributions from launch scope under #132, but long-term I could see us bringing them back with projects as a first-class entity (vs. just treating as endorsements as at launch: #103), so that we would have onboarding and annual reporting along these lines:
To me, specific legal structure matters much less than evolving a social contract of clear reporting on percentages in each bucket. A third class would be official platform partners (TD, OC, GHS, e.g.), who would produce transparency reporting to meet agreed-upon criteria. |
Please don't expand to cover Project Members (which I presume are ASF, Eclipse, NumFocus, etc. type orgs) until the original program has been running for a while and is well understood in the industry. The organizational decisions made on each side - companies vs. projects - in practice have wholly different kinds of incentives and flexibility, so it's really, really hard to come up with side-by-side metrics that would at least be kinda-consistent. Successful companies typically have a far, far more flexible model: if your CTO or VP, Product believes putting 2 more devs or a sponsorship on open source will help your bottom line, then you just do it. Easy - well, presuming you're the kind of company that's willingly supporting open source, which is part of what you're changing, yay! The actual nonprofits today have far more financial or practical contstraints on both what they do directly, as well as funding issues. Most nonprofits can't budget future expenses and growth the way commercial companies can - because we rely on sponsorships, not our own output to bring revenue. And where projects spent funding is frequently pre-determined either by nonprofit structure and ethos, or where in the marketplace of both contributors and possible sponsors they fit. This means companies could be incented to improve their numbers in obvious ways (if this pledge is successful); but in practice, many of the foundations here can't easily either 1) increase their numbers (we rely on sponsorships, which aren't always steady) or 2) necessarily change where they spend funds, because of structure. It's totally normal for the ASF to spend $0 on paying maintainers (it's against our ethos), and to net $0 for events (because we rely on events being self-sustaining in general, to avoid the early PSF event issue). It's also totally normal for NumFocus to spend a variety of funds on maintainers, because they host various projects with different grants or sponsorships. It's also totally normal for NumFocus to spend $2M+ on events, because they focus on broader end-user and scientific user events (and a lot of different events). So putting a big chart up that shows ASF next to NumFocus would be pretty misleading as a comparison within project members. Hope that makes sense. Really glad to see the depth of the different conversations around what, specifically, to showcase (and encourage!). |
Sir, yes, sir. 🫡 😌 😁 |
|
Bringing this back around to the original topic ... how about language like this to clarify what is in scope for Pledge payments?
|
|
I think that's pretty clear, and I think the focus on the “heart and soul” is important so that we ensure that maintainers get paid. But, to avoid confusion, we should also add some footnotes saying that (1) payments to foundations also count, and (2) paying maintainers via platforms such as thanks.dev counts, as long as the vast majority of the money goes to maintainers. This does definitionally result in Tidelift not counting. |
|
Take 2. Once we update this FAQ we should link there from /join.
|
|
Wordsmithing is hard, so this is just pundering:
|
|
Take 2 is great evolution. In terms of Foundations in general, that depends on how strict your goal is around actual cold, hard, cash in my hand as a maintainer for the actual code I produce. That cash is a key aspect of sustainability (i.e. the people doing un-evenly compensated work), but it's definitely not the only issue for maintainers' ability to regularly contribute and maintain work. Foundations provide the legal, organizational, reputation (trademark), infrastructure, and other stuff that absolutely is a direct help to maintainers working on projects there, because it reduces effort and risk for the maintainers personally around a host of issues. (examples) Sure, GitHub is easy to start a project, but foundations have infra teams that give you integrated CI/CD and often have free compute credits for your project. Even if maintainers don't know the costs, many definitely appreciate the free legal "insurance" they get contributing to code backed by a foundation. And long-term, foundation ownership of trademarks is absolutely something maintainers benefit from, because their reputation of work is tied to a stable and better-known project over time. One note: shouldn't you mention Tidelift on that page, even if you say "we're still quantifying if it counts", otherwise you'll get lots of submssions or questions on it? And Tidelift... that's the one model that in some ways is a critical effort at trying to change the relationship between maintainer & company holistically, and in some ways should count. On the other hand, if your definition is really limited to "maximal cash to help a maintainer write more code", then I can't answer that one without better understanding how much of Tidelift's overhead is focused on support for the sponsors, vs. long-term investment in the maintainer ecosystem. |
|
I think that, while we acknowledge that services offered by foundations, by Tidelift, and so on, are indeed very important and valuable to maintainers, those currently don't fall within the scope of the Pledge at all. Only things that get money to maintainers are in-scope, because this means that maintainers can live more sustainably and avoid eg burnout caused by working second shifts to maintain their projects. I think the reason to have some leeway there regarding foundations is that, while most foundations do not pay a significant amount of money to maintainers, foundations are very important to the ecosystem, and we would like to explore whether foundations would be willing to give more direct support to maintainers, but we acknowledge that foundations need more funding to do so. |
|
Let's move this to a PR: #168. |
Fwiw, we haven't gotten any questions about this from people actually interested in joining the Pledge, only from "sustainability nerds" (if you will). |
|
Otoh sustainability nerds are the ones most likely to read the FAQ. 😆 |
We did a lot of work in #45 to dial in the requirements for participation in the Pledge. We need to go further. Here's a list of cases on a spectrum surfaced (mostly; I added 7) by a potential Pledge member, with my take on what is and isn't acceptable to include when reporting Pledge payments:
The "money value of time" line item on reports is intended to cover 4, 6, 7, and 8.
5 is a gray area, projects have sponsorship tiers, we recognize that. Also some projects are more important to a company than others (@schacon goes into this in his post).
What does everyone think? We should reach some consensus on details like this and publish guidance on the website.
The text was updated successfully, but these errors were encountered: