Update requirements for participation #45
Comments
|
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? |
|
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 |
|
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 😁):
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 {
"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
}
]
} |
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. |
|
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. |
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. |
|
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. |
|
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. |
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. |
|
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). |
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. |
|
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. |
|
@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).
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. |
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). |
|
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. |
GitHub has an "Export as csv" utility for organization sponsorships — not sure what the data looks like yet because it's not "instant".
👍 |
|
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
}
] |
Both already have public APIs for this. OC directly exposes all public transaction details for every organization: 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): 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). |
|
Thought I'd keep this open for a bit longer. It sounds like what we're heading towards requirements-wise is:
This means we still have to:
It sounds like having GHS etc. as compliance vendors solves (1) and (2), but can it solve (3)? If not, we still have to:
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. |
In #46 I broadened this to |
|
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 |
|
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. |
|
Okay so call it
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. |
|
I would probably do a few things:
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?
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? |
|
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? 
|
|
@zanieb Regarding GH Sponsors export, there seem to be two possibilities for authentication: (1) We can create a GitHub App. This would be most convenient for users, because they would just have to authorise the app and get an export. However, the app would be controlled by us, so users might have to go through a procurement process for company policy reasons before being able to authorise our app which would introduce friction. Let me know if you have any thoughts on this! |
|
(2) seems fine to start. Easy to mount whatever we build as an app if/when there's demand. |
|
Okay, on it. I'll work on a demo and we can workshop the reporting format after. |
Yesterday ofc lol :P I don't think it's a hard blocker for onboarding Sentry and Astral but we do want to start strong with our first two members showing best practices. |
|
Work started here: https://github.com/opensourcepledge/osp-github-reporter (cc @zanieb) It looks like the GitHub API reports when a sponsorship started and ended. We need to use this information to determine the amount donated for the intervening months. |
|
We have per-month payment totals done (this is in cents): Getting those itemised by sponsorship will be much more involved. |
|
I took a look at this today and it looks quite complicated. At this point, I'd like to provide a document (e.g. a public spreadsheet) manually itemizing the amount we're giving to each project — the integration with GitHub really seems like something we'll need to coordinate with their team to achieve since their API doesn't make this information easily accessible. It definitely could be done externally, but I really have my hands full with my other engineering work. |
|
Yes, it's a bit of effort for sure. I would be able to do it at some point in the next couple of weeks. @chadwhitacre, just let me know if there are ever any internal Sentry discussions resulting in automatic GitHub reporting not being required, so I don't unnecessarily implement it. |
|
@chadwhitacre @zanieb I decided to say “heck it” and just write the code and see what happens. Here are my results for a reconstruction of the itemised payments made from my account, exported as CSV: You can see that they match my actual payments almost perfectly:
Here's the code: https://github.com/opensourcepledge/osp-github-reporter/blob/main/report.py Here are the usage instructions: https://github.com/opensourcepledge/osp-github-reporter?tab=readme-ov-file#usage There are also a few cavets, which I've documented in the README, but tl;dr:
@zanieb, and perhaps @chadwhitacre, and anyone else, would you be willing/able to run this on an organisational account, to see if these results are accurate? |
|
Onboarding for Sentry:
Then ... Astral. |
|
(2) & (3) done 💃 
|
|
Awesome work on the GHS exporter, @vladh. I was able to get it to complete successfully with this patch: diff --git a/report.py b/report.py
index 7f01645..c11a304 100755
--- a/report.py
+++ b/report.py
@@ -167,6 +167,8 @@ def reconstruct_payments(events, start_date, end_date):
def remove_sponsorship(login):
nonlocal payment_monthday
+ if login not in payment_login_to_amount_map:
+ return
del payment_login_to_amount_map[login]
if len(payment_login_to_amount_map) == 0:
payment_monthday = None
@@ -235,8 +237,11 @@ def reconstruct_payments(events, start_date, end_date):
login = event['sponsorable']['login']
match event['action']:
case 'NEW_SPONSORSHIP':
- monthly_price_in_cents = event['sponsorsTier']['monthlyPriceInCents']
- is_one_time = event['sponsorsTier']['isOneTime']
+ try:
+ monthly_price_in_cents = event['sponsorsTier']['monthlyPriceInCents']
+ is_one_time = event['sponsorsTier']['isOneTime']
+ except TypeError:
+ continue
payments.append(Payment(
date=formatted_day,
login=login,
diff --git a/requirements.txt b/requirements.txt
index 8826e37..64fccfc 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -1,2 +1,3 @@
+aiohttp==3.10.5
arrow==1.3.0
gql==3.5.0 |
|
Thanks @chadwhitacre, I'll apply that patch. Did the output of the program seem about right to you? |
|
Good enough for government work. :o) |
I think these can be the same. Annual report covers both. 🐭 |
|
@zanieb I think we're ready for Astral to publish an |
|
Onboarding instructions are now at osspledge.com/join. 👍 |
|
@dcramer, are the reporting requirements at https://osspledge.com/join/ in line with what you expect from members? It would be great to get your thoughts on this so we can know that the requirements are solid before we send out a batch of emails to potential members. |
Another way to ask is, are the listings at osspledge.com/members up to par? |
|
Word from @dcramer internally:
With that I am calling us good here! Thank you everyone for working through this conversation with us! We sussed out a lot of edge cases and detail and are getting the Pledge off to a solid start as a result. 👍 See you over in #5 and beyond! 🫡 |
Three things that I think need to be mandatory (with our without a JSON file):
1/2 are basically hard requirements for me, but lets talk about (3).
We want to ensure the community can do two things:
The text was updated successfully, but these errors were encountered: