Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify guidelines even further #112

Closed
chadwhitacre opened this issue Sep 14, 2024 · 47 comments · Fixed by #168
Closed

Clarify guidelines even further #112

chadwhitacre opened this issue Sep 14, 2024 · 47 comments · Fixed by #168
Labels
must have required for October 8 launch

Comments

@chadwhitacre
Copy link
Contributor

chadwhitacre commented Sep 14, 2024

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:

  1. Yes - Anonymous donation to OpenSSH - no recognition, no strings attached
  2. Yes - Public donation to OpenSSH- very little benefit from recognition, no strings attached
  3. Yes - Public donation to Drizzle ORM - a tool in our space (by donating publicly, we get some good will and recognition from prospects and customers), no strings attached
  4. No - Funding a developer outside the company to work on an open-source library
  5. Probably - Larger sponsorship of Drizzle - including the ability to request help from their team to work on a feature that makes the overall experience better for some of the company's customers.
  6. No - Funding a developer outside the company to work on an open-source library that is integral to our company's success.
  7. No - Funding a developer outside the company to work on an open-source project within our company's product ecosystem.
  8. No - Funding development of specific open-source features at Drizzle - that benefit both the company and the broader open-source ecosystem.
  9. No - Paying an invoice to Plausible - a commercialized non-vc-funded open source tool.
  10. No - Paying an invoice to PostHog - a commercialized and vc-funded open source tool.

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.

@vladh vladh added the must have required for October 8 launch label Sep 14, 2024
@vladh
Copy link
Member

vladh commented Sep 14, 2024

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

  1. https://www.openssh.com/

@voxpelli
Copy link

Copying a concern I raised on Discord to here:

If eg. company A donates to collective B whose main maintainer C is an employee of A

I think the spirit of the OSSPledge is to support the wider ecosystem, so would be good with similar wording as we added to the Collective Funds Guidelines regarding donating to projects one control oneself, at least in an FAQ part

We included wording like this in the CFG:

These funds should generally not go to projects maintained by members of this project as members should get compensated through the Project Development funds.

Also:

To ensure transparency and avoid conflicts of interest, contributors and TSC members should not request compensation from the project for specific work (e.g., features, bug fixes) that has already been directly funded by other sources, such as employer contracts

https://github.com/collective-funds/guidelines/blob/main/GUIDELINES.md

@voxpelli
Copy link

I think 4. should be allowed, depending on how it was structured.

I eg got funded by Platformatic to speed up the launch of neostandard – the nature of it was very similar to a classic Open Collective donation, only 1:1 this time

@dcramer
Copy link
Contributor

dcramer commented Sep 16, 2024

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.

@chadwhitacre
Copy link
Contributor Author

I eg got funded by Platformatic to speed up the launch of neostandard – the nature of it was very similar to a classic Open Collective donation, only 1:1 this time

@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.

@voxpelli
Copy link

Money donated to any Open Source Collective project are legally prohibited from being used for anything but furthering that project and the same expectation was on the sponsorship I got, but we had no specified deliverables.

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?

@chadwhitacre
Copy link
Contributor Author

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?

@voxpelli
Copy link

Contractor without a specific scope of work? Is that what we're saying?

Yes 👍 As an employee one can never be truly independent

@chadwhitacre
Copy link
Contributor Author

chadwhitacre commented Sep 16, 2024

Astro weirds me out. How do they make money? I don't find any business model in their funding announcement. I can't buy anything on their website—they offer no product or service for sale. Their site footer links to a "Partner with Astro" Notion doc: of the seven partnership opportunities, they lead with the sponsorship program which is a pass-through so it doesn't count, and two of the items explicitly say "no paid placement," so does that mean they make their money on integrations, retweets, case studies, and community recipes? Doesn't add up. All their talk is about the Open Source project. "Astro is and will always be MIT-licensed." Famous last words.

Update: Astro is developing a hosting platform called Astro Studio that is currently in closed beta.

I think the fact that Astro raises the money from others to invest in this may be irrelevent here.

Hrm ... possibly, but hear me out ...

If Astro contributes the requirements to open source projects within their ecosystem (but not part of their entity), does it qualify?

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.

@chadwhitacre
Copy link
Contributor Author

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.

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?

  1. Expressive Code–yes
  2. astro-vtbot–no
  3. Lucia–yes
  4. Volar–yes
  5. astro-eslint-parser–no
  6. Lexington–no

There is a mix. My feelings are mixed. 🤔

@ljharb
Copy link
Contributor

ljharb commented Sep 27, 2024

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:

  1. they have a clear support policy, showing what's EOL and not (100% up to them)
  2. they link to us somewhere as a commercial support option for EOL versions (no constraints on messaging/design from us)

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)

@chadwhitacre
Copy link
Contributor Author

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?

@ljharb
Copy link
Contributor

ljharb commented Sep 27, 2024

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.

@vladh
Copy link
Member

vladh commented Sep 27, 2024

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.

@ljharb
Copy link
Contributor

ljharb commented Sep 27, 2024

Awesome! When is the first report due?

@vladh
Copy link
Member

vladh commented Sep 27, 2024

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!

@ljharb
Copy link
Contributor

ljharb commented Sep 27, 2024

#146

@chadwhitacre
Copy link
Contributor Author

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:

  1. HeroDevs should not count the rev share towards the Pledge minimum (payments key in the JSON).
  2. HeroDevs should absolutely do its own storytelling in its annual report blog posts—"We love Open Source. Not only have we joined the Pledge, we also do rev share etc. etc."

@chadwhitacre
Copy link
Contributor Author

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.

  • Sponsorship of these foundations.
  • Payments through the following platforms: TD, OC, GHS, Liberapay(?)

It does still get iff-y around benefits ~= strings. For example:

  1. PSF membership comes with all sorts of benefits such as conference tickets and whatnot.
  2. Caleb Porzio famously uses GitHub Sponsors as the payment platform for a successful "sponsorware" business.
  3. Basically all platform payments come with some basic level of logo placement. What's more we want to celebrate companies paying maintainers—that's the whole point of the Pledge!

🤔

@vladh
Copy link
Member

vladh commented Sep 30, 2024

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 company's primary intention is paying maintainers
  • The vast majority of the money paid goes to maintainers
  • Services offered by the intermediate platform are secondary

@ShaneCurcuru
Copy link

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.

  • thanks.dev, or any other "payments get auto-split among dependency tree" system: should be yes? Because it's mostly going directly to maintainers without strings.
  • Tidelift, or other "buy a package from us, and we'll split among key dependencies" is a strong maybe, because as I understand it, the payments (minus fees, etc.) are primarily for responsible maintenance, not specifically what each funder is asking at different times.
  • GitHub Sponsors - does it matter if the recipient is an individual maintainer, an small group or project, or some small corporation formed around that project?

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:
https://fossfoundation.info/sponsorships

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!

@chadwhitacre
Copy link
Contributor Author

chadwhitacre commented Sep 30, 2024

HeroDevs should not count the rev share towards the Pledge minimum (payments key in the JSON).

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.

@ljharb
Copy link
Contributor

ljharb commented Oct 1, 2024

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.

@gusaus
Copy link

gusaus commented Oct 1, 2024

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):

  • Airbnb Fund: Provides funding for various open-source projects, with a focus on sustainability.
  • Indeed Fund: Supports nearly 30 open-source projects that improve job search and recruitment technologies.
  • Stripe Fund: Supports open-source projects to foster innovation in the software development ecosystem.
  • Sentry Open Source Fund: Provides financial support to key open-source projects that Sentry depends on.
  • Bloomberg FOSS Fund: Supports free and open-source software projects critical to Bloomberg's infrastructure.
  • FundOSS: Uses Quadratic Funding to match donations for various open-source projects.

This model simplifies the process for corporations while scaling contributions. Would contributions to these types of funds count toward the Pledge?

@ljharb
Copy link
Contributor

ljharb commented Oct 1, 2024

It seems like they should count for contributors, but not also count as contributions for the Open Collective fund itself.

@voxpelli
Copy link

voxpelli commented Oct 1, 2024

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 company's primary intention is paying maintainers
  • The vast majority of the money paid goes to maintainers
  • Services offered by the intermediate platform are secondary

In case of Tidelift I think it matches those apart from maybe the Services offered by the intermediate platform are secondary – I think the service they provide to the companies are as primary as funding maintainers – them aiming for a win-win situation (but they should answer that, not me 🙈 Edit: Shared in the Tidelift Slack to make them aware)

@voxpelli
Copy link

voxpelli commented Oct 1, 2024

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)

@voxpelli
Copy link

voxpelli commented Oct 1, 2024

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.

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.

@dcramer
Copy link
Contributor

dcramer commented Oct 1, 2024

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.

@chadwhitacre
Copy link
Contributor Author

If I'm reading @ljharb right he submitted #146 w/o including revshare, which means we can punt that convo (at least) until after launch.

@ljharb
Copy link
Contributor

ljharb commented Oct 1, 2024

That's correct.

@gusaus
Copy link

gusaus commented Oct 2, 2024

Following up on #112 (comment)

It seems like they should count for contributors, but not also count as contributions for the Open Collective fund itself.

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?

@tieguy
Copy link

tieguy commented Oct 3, 2024

Hi!

The foundation membership dues definitely count.

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:

The company's primary intention is paying maintainers

That's definitely why we exist.

The vast majority of the money paid goes to maintainers

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".

Services offered by the intermediate platform are secondary

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. 🤷🏽‍♂️

@chadwhitacre
Copy link
Contributor Author

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. 😌

@tieguy
Copy link

tieguy commented Oct 3, 2024

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:

The primary two USA options for Open Source and Free Software are 501(c)(3)'s (public charities) and 501(c)(6)'s (trade associations). 501(c)(3) public charities must always act in the public good, while 501(c)(6) trade associations act in interest of its paying for-profit members. ... IMO, the choice between the two really depends on whether you want the project run and controlled by a consortium of for-profit businesses, or if you want the project to operate as a public charity focused on advancing the public good by producing better Open Source and Free Software. BTW, the big benefit, IMO, to a 501(c)(3) is that the non-profit only represents the interests of the project with respect to the public good, so IRS prohibits the charity from conflating its motives with any corporate interest (be they single or aggregate).

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.

@chadwhitacre
Copy link
Contributor Author

chadwhitacre commented Oct 3, 2024

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:

  • Company Members report on:
    1. cash to projects ← launch focus
    2. gift-in-kind donations to projects
    3. number of FTEs working on Open Source projects for which the corp does not own the brand
    4. OSI-licensed projects for which the corp owns the brand
  • Project Members report on:
    1. R&D (research and development)—paying maintainers goes under here, also e.g. running a package repository
    2. GTM (go-to-market)—events and conferences go under here
    3. G&A (general & administrative)—trademarks,. legal, finance, fiscal hosting, etc.

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.

@ShaneCurcuru
Copy link

have parallel accountability on both company (consumer) and foundation/project (producer) sides with first-class membership on both sides

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!).

@chadwhitacre
Copy link
Contributor Author

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.

Sir, yes, sir. 🫡 😌 😁

@chadwhitacre
Copy link
Contributor Author

Bringing this back around to the original topic ... how about language like this to clarify what is in scope for Pledge payments?

What qualifies? The heart and soul of the Pledge is no-strings-attached payments to upstream maintainers. Start there. It's okay if you get non-exclusive logo placement or other acknowledgement for your payments, or an hour or two of consulting time with the project team, but anything beyond such minimal benefits puts the payment out of scope. Open Source projects that exclusively benefit your company or your company's own ecosystem are also out of scope. When in doubt, use your best judgement and be transparent in your annual report.

@vladh
Copy link
Member

vladh commented Oct 7, 2024

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.

@chadwhitacre
Copy link
Contributor Author

Take 2. Once we update this FAQ we should link there from /join.

What payments are eligible?

The heart and soul of the Pledge is no-strings-attached payments to upstream maintainers. Start there.

  • Open Source projects that your company controls are out of scope. If you own the trademark, it doesn't count.
  • Open Source projects that exclusively benefit your company or your company's own ecosystem are out of scope.
  • It's okay if you get non-exclusive logo placement or other acknowledgement for your payments, or an hour or two of consulting time with the project team, but anything beyond such minimal benefits puts the payment out of scope.
  • Payments to foundations are generally in scope, though most foundations today are not set up to pay maintainers (they focus more on conferences, trademarks, etc.). We hope that the Pledge will enable foundations to shift towards paying maintainers in the future.
  • Platforms such as Thanks.dev, Open Collective, and GitHub Sponsors are a common way to pay maintainers, though they can also be used to make payments that are out-of-scope for the Pledge.

When in doubt, use your best judgement and be transparent in your annual report.

@ShaneCurcuru
Copy link

Wordsmithing is hard, so this is just pundering:

  • What if: s/to upstream maintainers/to maintainers/ It feels like the true goal is to encourage paying out actual funds with no strings attached to the people who build the open source world, which is really all (reputable) maintainers, not just your own obvious upstream. Making explicit this is about all maintainers really helps drive the message home. This also makes for a great FAQ about upstream vs. all, and the reasons for broad support, not just your own upstream.
  • That's a great start for "benefits that are OK", which will be important to list out in more detail at some point, so self-reporters can easily see what should count, and it's consistent. Reviewing sponsorship models [1], it was pretty clear the difference between governance benefits (i.e. a board seat or votes on one, which is a major benefit to the sponsor), versus advisory benefits ("advisory council", or a quarterly briefing from project leadership, which is a minor benefit). Someday if we want to get really detailed in terms of "quantifiable amount of benefits from foundation sponsorship", we could see how much training credits/discounts are worth to companies (some foundations, esp. LF, provide those in bulk).
  • Oh, wait, Chad just posted Take 2 right now... looking!

[1] https://fossfoundation.info/sponsorships/numfocus

@ShaneCurcuru
Copy link

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.

@vladh
Copy link
Member

vladh commented Oct 7, 2024

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.

@chadwhitacre
Copy link
Contributor Author

Let's move this to a PR: #168.

@chadwhitacre
Copy link
Contributor Author

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?

Fwiw, we haven't gotten any questions about this from people actually interested in joining the Pledge, only from "sustainability nerds" (if you will).

@chadwhitacre
Copy link
Contributor Author

Otoh sustainability nerds are the ones most likely to read the FAQ. 😆

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
must have required for October 8 launch
Projects
None yet
Development

Successfully merging a pull request may close this issue.

8 participants