Update requirements for participation

[dcramer]

Three things that I think need to be mandatory (with our without a JSON file):

1. A URL needs to exist on the corporate domain that articulates their open source investments.
2. Every calendar year, a report must be published on the corporate domain (e.g. not just a JSON payload we suck in)
3. Annual reports must itemize which projects and/or foundations money has been contributed to.

1/2 are basically hard requirements for me, but lets talk about (3).

We want to ensure the community can do two things:

1. self-police that people are actually giving the money they say they're giving (e.g. we cant require they give it via a public channel like GitHub)
2. shame companies who participate and say give 100% of the budget to the Linux Foundation (sorry LF, thats not the point of this pledge)

[dcramer]

fwiw (3) requires work, but I think that work is valuable. I also think we should figure out how we minimize the work on participating companies, but we do want the marketing (publishing annual reports) and self-accountability ("show me the receipts").

The one thing that would be super controversial is if (3) required you to publish the amounts or not. Could go either way here, but as an example, lets say you sponsor $5 to 100 projects each, are you going to get shamed for something we think is a good thing because that $ amount is low?

[mitsuhiko]

For (3) there might also be a potential inverse problem. Not that I condone trickery but I can imagine that there are legitimate reasons why a company might not want to reveal contributions to some specific Open Source projects. Obviously one way would be to say those type of contributions would have to be "on top".

[dcramer]

For (3) there might also be a potential inverse problem. Not that I condone trickery but I can imagine that there are legitimate reasons why a company might not want to reveal contributions to some specific Open Source projects. Obviously one way would be to say those type of contributions would have to be "on top".

Yeah, though I think without the itemization accountability basically doesn't exist, and I think most folks would agree this effort is silly if all it did was require some big company who funds e.g. one big foundation to just say they do that.

We could also just argue that in the spirit of open source - freedom and transparency - the price to pay is disclosure of contributions. Similar to what you'd want out of a non-profit.

To protect the exact amounts we could also simple normalize into buckets? <=5k/year, <=50k/year, >50k/year or similar

[chadwhitacre]

Okay so using https://httptoolkit.com/data/oss-pledge.json from #41 as an example (inlined below to snapshot it for discussion and posterity; and cc: @pimterry congrats on being the guinea pig 😁):

1. The ask is for urlLearnMore to point to a more specific page. Something like this one from Microsoft is the example I've been using in onboarding calls. I don't have a great one for Sentry yet even though I've been talking about it forever. 😬
2. For this I think we can add a url (or maybe marketingUrl and rename the global to match? clarify intent) field to the annual report objects. I'd like to allow retroactive reporting at the outset here as @pimterry has done, so maybe optional if year < 2024.
3. Here I don't actually care about every single last detail. If I saw ecosystems at a high level that would be plenty. "Sentry paid PSF, DSF, OpenJS, and Rust? Okay, cool." Honestly I want to make it the foundations' problem to distribute money to individual projects and maintainers in their ecosystem anyway.

Whatever we land on here, we should update the onboarding docs and adopt a process of vetting these as a part of PR review when adding to members.csv.

{
  "domain": "httptoolkit.com",
  "datetimeModified": "2024-08-06T16:10:00Z",
  "name": "HTTP Toolkit",
  "description": "HTTP Toolkit is an open-source tool for debugging, testing & building with HTTP. Like all modern software projects, it stands on the shoulders of a huge variety of other open-source components, and it aims to return a substantial portion of revenue back to its key dependencies to fund maintainers, ensure each project's longevity, and help grow the open-source community.",
  "urlSquareLogoWithBackground": "https://httptoolkit.com/logo/logo-red-bg-200px.png",
  "urlLearnMore": "https://httptoolkit.com/",
  "annualReports": [
    {
      "dateYearEnding": "2023-12-31",
      "averageNumberOfDevs": 1,
      "monetaryPayments": [
        {
          "amount": 2855,
          "urlDetails": "https://opencollective.com/http-toolkit"
        },
        {
          "amount": 1460,
          "urlDetails": "https://github.com/httptoolkit"
        }
      ],
      "monetaryValueOfTime": 0,
      "monetaryValueOfMaterials": 0
    },
    {
      "dateYearEnding": "2022-12-31",
      "averageNumberOfDevs": 1,
      "monetaryPayments": [
        {
          "amount": 1920,
          "urlDetails": "https://opencollective.com/http-toolkit"
        },
        {
          "amount": 664,
          "urlDetails": "https://github.com/httptoolkit"
        }
      ],
      "monetaryValueOfTime": 0,
      "monetaryValueOfMaterials": 0
    }
  ]
}

[dcramer]

For this I think we can add a url (or maybe marketingUrl and rename the global to match? clarify intent) field to the annual report objects. I'd like to allow retroactive reporting at the outset here as @pimterry has done, might get futzy but maybe its optional if year < 2024.

Its not marketing, its the formal report. Its the accountability. Its great if thats in JSON, but I want to see it on behalf of the corporation. It just happens to also implicitly be marketing. I'm a hard no on referring to it as marketing, and I just want yall to understand what the delta is.

This whole thing is about accountability for me, and ultimately this entire program is about marketing. It's a big program to market the fact that people should do this, people do do this, and to shame the folks who talk and don't act.

[vladh]

It seems that there are two different evaluations of potential members. The first one is one we make: who should be allowed to be a member, i.e. be on the website and use the logo? The second evaluation is made by the community: which contributions are more or less shameworthy or praiseworthy?

Here's one idea. I agree with requiring itemised receipts to ensure accountability. We can say that, in general, we require itemised receipts with amounts, and as long as you meet the minimum pledge, you're a member.

However, members are also allowed to redact some line items, if they provide a short explanation for the reasoning of each redaction, in exceptional situations such as what @mitsuhiko described, and in this situation, the item will be visible to the community as having been redacted.

This means that the community sees (1) any potentially objectionable redactions and their explanations, and (2) the distribution of donations, and they can make their own judgments based on these things, which might not be for us to decide.

The accountability here might rub certain companies the wrong way, but I would be surprised if that was more than a minority; but maybe I'm wrong.

[chadwhitacre]

its the formal report. Its the accountability.

I think we want to incentivize growth of ecosystem players to handle this. It surfaced here that what we're doing could be a conceptual fit for vendors like SafeBase so a company's annual Pledge report would be hosted on e.g. https://trust.neon.tech/.

I honestly don't care to make companies do a ton of work or jump through hoops. The simpler the better. "We use JavaScript, Python, and Go. We have 1000 devs. We cut a check for $2,000,000 to Thanks.dev and they did the rest. We got a page on osspledge.com and a badge for our footer." At the end of the day that is more money to OSS and if companies don't care to maximize their marketing opportunity then that's their loss.

Otoh we do want network effect. I think that'll happen naturally tho esp. at the outset as ofc most/many companies do want to maximize their marketing opportunity here.

Brainstorm: only companies that market the Pledge on their domains are included in #13.

[dcramer]

I don't care if vendors make it easier over time, but I'm not budging on the requirement of reporting. People are able to do it, we need them to do it. If that means a handful of people drop out that don't actually care about the results so be it. They're either still funding things or they never cared in the first.

Ultimately this is a hard requirement and was one of the original components of this project. Its fine that we didn't completely dial in exactly what it meant and have to adjust now, but we're not removing that requirement. I'm not going to dictate whats in the report, as per the description of the ticket, but I do think its in our best interersts to force them to disclose what they contributed funds to.

[zanieb]

For what it's worth, I'm excited about funding open source and being a part of this project but as an engineer at a tiny startup, it's hard to justify spending a bunch of time creating regular reports of the projects we're sponsoring. I understand not caring if big companies are discouraged by this, but it seems especially detrimental to small companies with less resources and I feel it's important to get people involved at all scales.

Perhaps it'd be helpful to create a script to convert data from common platforms, e.g., an export from GitHub Sponsors, to your desired format.

[dcramer]

Perhaps it'd be helpful to create a script to convert data from common platforms, e.g., an export from GitHub Sponsors, to your desired format.

100% - that is the ideal outcome. OC/Thanks.dev/GH just become "easy mode". Whether they solve it, or we help them solve it.

fwiw I think a debatable part is if we would require itemization per project, or simply per sponsor destination. GitHub Sponsors generally implies something already.

[pimterry]

Speaking for the very-small-company pledger audience, I do understand the accountability & marketing goals, but committing to writing up a formal report every year is a bit of discouraging overhead for any small-ish org getting involved.

Taking HTTP Toolkit's case above, and making this concrete - could we aim to say that maybe that every monetaryPayment listed needs to link to either a publicly verifiable source (in this example: GH sponsors + Open Collective) or a public written report of how those funds were delivered? I don't think there's much accountability benefit to writing annual reports for donations that are already verifiable anyway.

That would resolve accountability while keeping pledger overhead requirements minimal.

It also helps with pledge onboarding, even for large orgs, for everybody primarily donating via such platforms (I suspect this will be a large percentage). No need to spend time writing and getting internal approvals to publish formal reports or anything - if you can link to existing verifiable public donations then you're in.

It doesn't help with marketing out of the box, but given this data we can easily generate OSS Pledge branded annual reports directly (complete with company logos & descriptions etc, just from the JSON already defined here). If OSS pledge generated a nice end-of-year "HTTP Toolkit donated $X to Y projects in 2024. Here's the full details..." page or PDF report or something, pulling data from those public platforms for me, that's absolutely something that I'd publish and promote publicly. That works very nicely as marketing output for both the orgs & the pledge itself, and it's basically free from the data you'll already have. Hosting those reports on osspledge.com also pushes up the SEO there and directly drives a funnel for more pledge signups (rather than just writing annual reports on httptoolkit.com about open source & HTTP Toolkit with just an OSS pledge logo, which primarily drives my signups - great for me, but less good for the wider goal).

[mitsuhiko]

Taking HTTP Toolkit's case above, and making this concrete - could we aim to say that maybe that every monetaryPayment listed needs to link to either a publicly verifiable source (in this example: GH sponsors + Open Collective) or a public written report of how those funds were delivered? I don't think there's much accountability benefit to writing annual reports for donations that are already verifiable anyway.

From "link to common platform" to us working with the common platform to automatically get an export there isn't a ton of difference to be honest. At that point why not just walk to the destination directly.

Low friction are definitely important concerns and it should be be laborious for smaller companies but I think it's crucial that this does not turn into another random intransparent ESG certification program.

[vladh]

Regarding creating an Open Source Pledge report based on company data — we have to do that anyway, right? Say Foocorp reports in 2024 and includes a link to http://github.com/foocorp. In 2025, that link might contain totally out of date information, so we have no historical record of what was actually donated. So it would make sense to record the publicly available contributions at the time of reporting. And if we have that, generating an HTML/PDF report with Open Source Pledge branding is ~free.

[chadwhitacre]

@zanieb I think the post yinz published last month is exactly the sort of thing @dcramer (correct me if I'm wrong) is calling a report, same as Sentry has done the past three years: 2023, 2022, 2021. @pimterry Can you take a look at these and let us know if a blog post along similar lines seems like a reasonable ask?

If so then my thinking at this point is that for Cramer's (2) we should simplify what we ask for for the website, basically just a URL to a report as described above rather than N links to various platforms. Because in all likelihood if/when this scales, any given company is going to pick one OSS Pledge compliance vendor and not bother with multiple platforms. For those of us who do, we can continue to do "manual" reports (if you will).

OC/Thanks.dev/GH just become "easy mode". Whether they solve it, or we help them solve it. us working with the common platform to automatically get an export

Yeah, we could steer this at the OSS Pledge level by certifying compliance vendors, so that we can basically trust the quality of the reports they're providing. Honestly it would make our job easier and likely improve the overall outcome because with manual reports we will have to do a lot of one-off inspection to ensure quality (in some ways similar to BUSL vs. FSL for those also tracking Fair Source). Better to incentivize ecosystem partners to take on the burden of report QA, imo. Realistically there's only a handful: GHS, OC, TD, Tidelift, maybe a couple more we would invite. That way we would be hashing out report specifics with a small number of people ready to take that on vs. asking a large number of individual companies to shoulder the burden as we're doing here.

[chadwhitacre]

incentivize ecosystem partners to take on the burden of report QA

The next step if we're aligned on this as a mid-term goal would be to start a separate thread to track conversations with GHS/OC/TD/etc.

Immediate term we will need early adopters to do manual reports along the lines identified above (i..e, blog posts like Sentry's and Astral's).

[dcramer]

For the reporting, are there APIs or any easy way currently to export projects on GH/OC?

The publishing of the report on the website, this is hard requirement from Sentry. Folks may not understand it, but this is how these things gain ground. We need real companies to publish real self-accountable reports on their own properties. That doesn't matter the size of the company ultimately. Without that this thing has no legs, and we're trying to affect change ultimately, and particularly change within technology companies. What Chad has mentioned regarding that is what I'm talking about. Its not a lift to write up a simple report of how much was contributed and to where. It's better if its not vague like "50k to open source" and at least more "50k to projects on GitHub Sponsors".

For what is required to be reported on, we still need to define some degree of specificity here. What I don't want to see is vague reporting requirements, to where someone can say 100% of their donations went to Foundations, and have the report leave it as that. Again I think the model here is to look more at what good charities do. We need some degree of receipts here.

I also want to make sure that everyone recognizes what the goal looks like. We're trying to get corporations to contribute back financially to to the ecosystem they leverage. While it's great that there's many individuals, or companies-of-one that do more than their fair share, and thats certainly worth celebrating, if we optimize for that we've ultimately missed the real opportunity. If we normalize this program amongst growth mode startups that alone will have an impact on the industry. If we can turn that into even a fraction of enterprise companies giving, it will eclipse all individual financial contributions across the entire industry.

[zanieb]

For the reporting, are there APIs or any easy way currently to export projects on GH/OC?

GitHub has an "Export as csv" utility for organization sponsorships — not sure what the data looks like yet because it's not "instant".

It's better if its not vague like "50k to open source" and at least more "50k to projects on GitHub Sponsors".

👍

[chadwhitacre]

Moving to a PR in #46, simplifying to:

  "annualReports": [
    {
      "url": "https://blog.sentry.io/we-just-gave-500-000-dollars-to-open-source-maintainers/",
      "dateYearEnding": "2024-01-31",
      "averageNumberOfDevs": 135,
      "paymentsToProjects": 500000
    },
    {
      "url": "https://blog.sentry.io/we-just-gave-260-028-dollars-to-open-source-maintainers/",
      "dateYearEnding": "2023-01-31",
      "averageNumberOfDevs": 130,
      "paymentsToProjects": 260280
    },
    {
      "url": "https://blog.sentry.io/we-just-gave-154-999-dollars-and-89-cents-to-open-source-maintainers/",
      "dateYearEnding": "2022-01-31",
      "averageNumberOfDevs": 75,
      "paymentsToProjects": 155000
    }
  ]

[pimterry]

For the reporting, are there APIs or any easy way currently to export projects on GH/OC?

Both already have public APIs for this.

OC directly exposes all public transaction details for every organization:

curl "https://api.opencollective.com/v1/collectives/http-toolkit/transactions" -H "Content-Type: application/json"

Docs here: https://docs.opencollective.com/help/contributing/development/api/collectives#get-transactions-from-collective. Automating reporting from there should be super easy.

GH lets you collect all the current sponsorship state data directly with GraphQL, including sponsorship start dates (including past sponsorships, but with no end dates AFAICT):

query($orgLogin: String!) {
  organization(login: $orgLogin) {
    ...OrgSponsorships
  }
}

fragment OrgSponsorships on Organization {
  sponsorshipsAsSponsor(first: 100) {
    nodes {
      sponsorable {
        __typename
        ... on Actor {
          login
        }
      }
      tier {
        monthlyPriceInDollars
      }
      createdAt
      isActive
      isOneTimePayment
    }
  }
}

Requires a GH token, but works for the public donations of every org (so no need for the oauth dance). Docs here: https://docs.github.com/en/graphql/reference/objects#sponsorship

Bit more complicated, but easily gives enough to calculate a current recurring total, provides ongoing validation if you query at frequent intervals, and a lower bound of past donations (depending on how many have since been cancelled).

[vladh]

Thought I'd keep this open for a bit longer. It sounds like what we're heading towards requirements-wise is:

1. Minimum amount
2. Itemised to some degree
3. To independent maintainers

This means we still have to:

• [ ] Define what “independent” means
• [ ] Determine which requirements we expect compliance vendors to meet
• [ ] Provide guidelines on what degree of itemisation is acceptable for a manual report

It sounds like having GHS etc. as compliance vendors solves (1) and (2), but can it solve (3)? If not, we still have to:

• [ ] Decide who, and based on what rules, will review reports to determine whether they're compliant esp. wrt. “manual” reports

Also, am I correct in understanding that this all means that we will not be ingesting any kind of numerical reports ourselves, because the numerical reports will either come from the compliance vendors, or only be on the report blog posts in the case of a manual report?

And just to be clear, do we expect companies that use compliance vendors such as GHS to still publish somewhat itemised numerical reports on their report page? Because if so, one might ask whether it's worth going through compliance vendors, when the manual reporting mostly needs to be done anyway.

[chadwhitacre]

To independent maintainers Define what “independent” means

In #46 I broadened this to paymentsToProjects, because "independent" was not clear. I mean to include both individuals and foundations, any entity that is independent of the company member (not just "indy maintainers" i.e., individuals).

[dcramer]

a foundation still doesnt imply a project, why dont you just call it payments?

foundations have no requirement to actually maintain the software, they could be for any number of purposes in the ecosystem at the end of the day

goal is to fund maintainers ultimately, so we should not try to make that fuzzy

[vladh]

Wording suggestion: to meet the requirements for the pledge, a company's report must show them donating the minimum amount directly to open source maintainers (presumably that maintain projects they depend on), which can take the form of any legal entity. They can also donate to non-maintaining e.g. foundations but this does not count towards the minimum amount, so I can't give $1000 to a maintainer and $1000 to the Linux Foundation.

[chadwhitacre]

Okay so call it payments.

a company's report must show them donating the minimum amount directly to open source maintainers

How are we going to ensure this? PSF is on GHS, PHP is on OC, so we can't just say "If it's on this platform it went to maintainers."

I think it's hard to get away from involving foundations in the overall success of the Pledge (cf. #37). One path would be inviting them to submit reports as well, with a minimum spend on maintainers vs. marketing, events, etc.

[dcramer]

I would probably do a few things:

1. Be clear on the goals up front (we are: pay maintainers).
2. Include foundations in those payments - they do maintain software after all.
3. (Possibly) Separate out direct payments to projects/maintainers vs foundations. Agree w/ the GHS/OC not being entirely exclusive to directly paying maintainers, but its much closer.

I think we should step back and ask ourselves what the absolute best mechanisms are to showcase maintainers are getting paid, and then find the compromise from there. There's a few things I want to reiterate that come to mind here:

If you itemized every payment, well that does it pretty well. Obviously some will be foundations, and its up to the community to vet those foundations (same as other charities) to make sure they're spending the money effectively.

So what are the problems with itemizing every payment?

• Burden - its potentially a lot of work. Maybe that's something we can solve by working w/ the platforms.
• Sensitivity - knowing exactly how much you have given to every single project might be too much detail. I dont think its that valuable, and I'm worried folks will object.

So the question then becomes: is that level of detail too much? How could we reduce it? The sensitivity thing is easy to solve by fuzzing the amounts (bucketing them), the burden is solvable with tools - but still creates some friction. Both of thse are potential objection points that I want to be concious of.

At the same time we need to make sure this does the best job of influencing the goal we have (paying maintainers), so is there a different, less objectionable version of reporting that we could mandate? $ to maintainers? $ to foundations? do we force itemization of those foundations but not the projects/maintainers?

Is there anything else I'm missing?

[chadwhitacre]

We have a pretty good list of foundations, there's only a handful (< 50) compared with the long tail of maintainers (500+ in a dependency graph). We could itemize those separately and have a catch-all for direct to maintainer. Does this look closer to what we want?

[chadwhitacre]

"Direct to Maintainers" would/could link out to platforms for detailed receipts, though if you pay foundations through platforms we would need to address that one way or another. It might not fit in one table.

[vladh]

One point of worry for me is that, for example, as far as I can tell, neither the Python Software Foundation nor the Apache Software Foundation actually pay maintainers, so if I give $1000 to one and $1000 to the other, I haven't actually given any money to maintainers. If I give $500 to each of those two, and $1000 directly, I'm only meeting half the pledge. Unless I'm wrong here?

(For another example, the Rust Foundation seems to spend something like 30–35% of expenditure on maintainers.)

[chadwhitacre]

PSF does a little bit (underwritten by LF via Alpha-Omega, fwiw).

Spitballing ... we could maintain a percentage for each foundation in the list, and use that in the computation of $/dev. Made-up numbers:

Foundation	% Budget Core R&D	% Budget Ecosystem R&D
PHP	95	0
Rust	35	10
Python	5	5
LF	3	1

[dcramer]

@chadwhitacre imo think thats too much work on the pledge community - safer to just force people to disclose if thats what we want, since ultimately we want to know "are they funding maintainers or just giving all their money to one foundation in the hopes it does something useful"

[zanieb]

I like the "Direct to maintainers" and "Foundation" split — we've separated those budgets separately internally as well.

I think the PSF does fund maintainers. At least, that's the expectation for some of the money we're giving them for CPython and PyPI maintenance. I could seek more details, if you thought it was particularly important. I think supporting foundations is important regardless of a percentage going specifically to maintainers.

[dcramer]

A question came up from a potential member:

They sponsor a bunch of their projects-related indepdent projects. In Sentry's context, that'd look like a third party building an open sourcing a GitHub integration, and then us sponsoring it. While that's a good thing, that's obviously not in the spirit of the pledge (e.g. that's funding maintainers of effectively your own software or its ecosystsem, vs maintainers in general). I'm not totally sure how we codify that, but given we're talking about all of that here I thought it was worth documenting. I don't think this needs to affect e.g. the report/JSON payload, but we should at least make sure the funding intentions are clear.

[zanieb]

Definitely agree with that — that was an important discussion we had early in our OSS Fund initiative. Also, things like paying maintainers for extra functionality, e.g., in the style of MkDocs Material Insiders.

[chadwhitacre]

Fwiw I'm treating the JSON payload right now as very simple, just links to the "real" report hosted on company domains. Mostly a way to keep osspledge.com a static site and also avoid adding more PR friction, company makes one PR at the outset and then they can self-serve update their info whenever they want, the automations @vladh built out will pull that in for us. It does mean we have to think about re-vetting companies, but I guess our model there is "community can inspect at any time"—i.e., trust and verify (after initial onboarding) vs. review every time before publishing. (Should also think through possible security concern, tho I don't think there's much since we're a static site.)

[vladh]

@chadwhitacre I think we should add optional GHS/OS/etc. usernames to the schema. Regardless of what reporting requirements we decide on, having those usernames available allows us to fetch some useful data from those APIs if need be. What do you think? If this sounds good to folks I can also propose a schema and a PoC for fetching sponsor data.

Note that, because data from donation platforms changes over time, this means we would have to fetch the donation data at the time of JSON report submission, and store it somewhere.

[chadwhitacre]

There's seemingly no harm in adding these as options to the schema. Otoh if they're not required, then are they that useful? We'll only have partial data, right? Are the uses cases you have in mind related to a single member, or aggregations over all/many members, or ... ?

[vladh]

@chadwhitacre Here's an example. Say Sentry makes donations on OpenCollective, and Sentry sends a report which includes opencollectiveUsername: 'sentry'. We can then query this URL: https://api.opencollective.com/v1/collectives/sentry/transactions. This gives us all transactions made by Sentry on OpenCollective, which solves the receipts problem cleanly. Of course, this will not work in all cases. But it seems wise to enable this best-case scenario.

[chadwhitacre]

This gives us all transactions made by Sentry on OpenCollective, which solves the receipts problem cleanly

I'd rather make this the platform's problem. GHS/TD/OC etc. could/should each add an Annual Report for us. Keep OSS Pledge as thin as possible.

[chadwhitacre]

Again I think the model here is to look more at what good charities do.

Gonna dig into these for inspo:

• GuideStar
• Charity Navigator
• Give.org
• CharityWatch

Lmk if there are others you're aware of.

[chadwhitacre]

Gonna dig into these for inspo

GuideStar → Candid

GuideStar merged with Foundation Whatever and is now called Candid. Their rating system is called "Seals of Transparency." Here's a blog post intro and here's the full PDF (mirror). They use a bronze / silver / gold rating system. Notably, they have a partnership with Apple: non-profits must earn at least bronze in order to use Apple Pay. (Apple uses Benevity outside the U.S.A.)

Charity Navigator

Charity Navigator has a 66-page "Rating Methodology Guide" living Google Doc(!). They call their rating criteria "beacons." There are four and they roll up to a 100-point scale. They include all registered 501(c)3s on their website. They rate the subset that have public 990s. Organizations can maintain a profile to actively participate in rating.

Give.org

Give.org is part of the Better Business Bureau (BBB). Their accountability system is based on 20 "standards" graded yes / no / unclear and grouped into four themes (a little info on their development). Give.org assesses and publishes reports about charities for free upon request. They charge charities for a license to display the BBB Accredited Charity Seal.

CharityWatch

CharityWatch bills itself as serving the interests of donors, independent of the influence of charitable organizations. They trade off depth of investigation for breadth, only covering 600 organizations, to which they apply an A+ to F rating scale.

[chadwhitacre]

Proposal from @dcramer in private email:

Publish annually a report on your corporate domain that details your open source contributions. It should, at minimum, include a breakdown of:

• Total amount of financial contribution, $ per/developer, and amount contributed directly to projects (such as via GitHub Sponsors or Open Collective).
• Distribution of contributions between maintainers, foundations, and other related entities.

Remember, the purpose of the pledge is to fund all open source, which is why we are focused on disclosure of contributions to projects and projects maintainers vs just foundations.

It is recommended, but not required, to:

• Disclose any other significant contributions you make to open source, including projects that you have contributed or employ staff to maintain.
• Itemize and disclose contributions of projects and foundations. We suggest bucketing these into three categories: <$500/year, $500-$5k/year, and $5k+/year.

I'm going to vet the Sentry and Astral blog posts against this. Ideally they check out and we can onboard Sentry and Astral as our first two members, and then update the onboarding docs and start bringing on additional members. 🤞

[chadwhitacre]

$500/year, $500-$5k/year, and $5k+/year

P.S. Not sure this scales, larger orgs may very well not do anything less than $5k/yr.

[chadwhitacre]

Astral's post seems great:

We're starting our fund at $26,000 per year: $16,000 for open source projects and maintainers, and $10,000 for non-profit language foundations. This comes out to $3,250 per developer at Astral.

We're giving between $20 and $150 per month per project, plus another $10,000 to language foundations

The following individuals and projects have been selected for this round of funding, which will be reviewed and expanded quarterly: [list of recipients]

$5,000 per year to both the Python Software Foundation and the Rust Foundation.

I'm gonna say this is pretty close to a model post. The only thing I'm left wondering at the end of it is whether the $26,000 has already changed hands or whether it's promised to be paid out over the coming quarters / year. To my mind Pledge annual reports should report on money that has already been paid (and therefore tbh reports may most naturally be published after the end of a fiscal year). That said, GitHub Sponsors does not make this easy, as they force you to set up monthly payments into the future to retain logo placement vs. one-time payments in view of past value.

[zanieb]

As a small note, Astral's current contributions to project maintainers range from $240-$1800/yr and we do not include an itemized amount per project.

Glad you liked my post :)

Whether the $26,000 has already changed hands or whether it's promised to be paid out over the coming quarters / year

This is a little complicated since it was an announcement that we were starting the fund rather than a end of year report. The amount to individual contributors and project maintainers is promised over the next year, in the form of monthly payments. The amount to foundations is intended to be a lump sum rather than a monthly amount i.e. we gave $5000 to the Rust Foundation but part of the $5000 to the PSF is delayed because we had already given them some money earlier and it's easier to give the rest when our contract renews.

I agree it makes sense for the annual reports to be based on already-paid money, but also if you want a low barrier to entry for organizations it'd be disappointing to wait a full year before being accepted into the program. I feel like that we have "pledged" to give the money (and are demonstrating that we are) should be sufficient to start. We should publish an end of year report and if that is lacking in some regard then membership can be revoked?

[chadwhitacre]

I feel like that we have "pledged" to give the money (and are demonstrating that we are) should be sufficient to start.

For the record I never liked the word pledge for this very reason. 🫠

if you want a low barrier to entry

I would say in general we don't, but there are differences of opinion on this and the specifics of what that means.

Hmm ... 🤔

[zanieb]

... we do not include an itemized amount per project.

As a minor clarification: we did not include these in the blog post, but I'm not opposed to publishing these amounts publicly in general.

[chadwhitacre]

@zanieb Was it an intentional decision on Astral's part to set up payments as monthly recurring into the future vs. one-time now? What did that look like?

[zanieb]

Yeah, there is a note in my original proposal (internal) that we should pursue monthly payments. I don't think there was much discussion about it though, we mostly focused on the difficulty of communicating that the payment would not continue in perpetuity but also that people could rely on it for some amount of time. I think this was driven, in part, by our existing sponsorships being oriented around monthly payments.

[chadwhitacre]

Alright I synced w/ @dcramer out-of-band, we're good to move forward with onboarding Sentry and Astral. 💃

[chadwhitacre]

Here's the PR to publish osspledge.json on the Sentry side 🔒. Look right?