Great idea, I think there should be some conditions.

a) you should not be the owner (to avoid pet projects that are not actually useful) of the project or at least not the sole owner

b) ideally it should be some high impact projects that have little to no corpo sponsors as opposed to something like React

c) if your contribution is not merged in, it should not count as "work done"

▲

sReinwald an hour ago | parent | next [-]

I think point a) is actually backwards and potentially counterproductive to the petition's stated goals.

The petition explicitly highlights maintainer burnout and the "unausgewogene Verantwortungslast" (unbalanced responsibility burden) as core problems. Excluding project owners/maintainers from recognition would exclude precisely the people carrying the heaviest load – the ones triaging issues at 2am, reviewing PRs, making architectural decisions, and bearing the psychological weight of knowing critical infrastructure depends on their continued engagement.

The XZ Utils incident is instructive here: the attack vector was specifically a burned-out solo maintainer who was socially engineered because he was overwhelmed and desperate for help. If anything, recognition and support structures should prioritize these individuals, not exclude them. Your concern about "pet projects with no impact" is valid, but the solution isn't to exclude owners categorically – it's to define impact criteria. A threshold based on adoption metrics, dependency chains, or inclusion in public infrastructure would filter out portfolio projects without penalizing the people doing the most critical work.

Point c) also seems problematic for similar reasons: much of maintainer work isn't "merged contributions" – it's code review, issue triage, documentation, community management, security response. Under your criteria, the person who reviews and merges 500 PRs per year while writing none themselves would receive no recognition.

The petition is trying to address a structural problem where society extracts massive value from unpaid labor while providing no support structures. Excluding the most burdened participants seems like it would perpetuate rather than solve that problem.

▲

withinboredom 27 minutes ago | parent | prev | next [-]

> if your contribution is not merged in, it should not count as "work done"

I highly disagree with this. Sometimes someone has to do the work to discover that isn't the work that should be done. As an example, last week, I got in a fight with the Go scheduler: https://github.com/php/frankenphp/pull/2016 -- in the end, we were able to find the one-liner that is a happy-medium. I didn't open that PR, but I did the work; if that makes sense.

▲

huqedato an hour ago | parent | prev | next [-]

Agree but... these would be hard and expensive to assess objectively, in particular point b.

▲

darkmighty 38 minutes ago | parent | next [-]

Does it need to be objective though? I think a vague list of criteria including "The project must benefit a community", or "The project must not be made solely for the benefit of their employer", and have someone review the proposal should be enough.

▲

asah an hour ago | parent | prev | next [-]

??? seems straightforward... among other things, require the applicant to do the work / provide evidence...

▲

londons_explore an hour ago | parent | prev [-]

Some government team could just make a list of allowable projects, updating it every year, and starting for example with all projects with over 100 GitHub stars or some similar metric.

	▲	threeducks an hour ago \| parent \| next [-]
		> all projects with over 100 GitHub stars or some similar metric. I think it would be difficult to come up with a good metric. For example, it should not be based on some easily faked number governed by a foreign company.
	▲	an hour ago \| parent \| prev \| next [-]
		[deleted]
	▲	LtWorf 41 minutes ago \| parent \| prev [-]
		> all projects with over 100 GitHub stars Lol, they have been on sale online since forever, because investors apparently can be conned into thinking they have some value.

▲

denismenace an hour ago | parent | prev | next [-]

Would Linux count as a project with corpo sponsors?

▲

whstl an hour ago | parent [-]

Yeah, Linux definitely has corporate sponsors. This is not a good rule of thumb.

React is also now owned by the React Foundation, so I also don't see why it would be problematic to contribute to it now that it doesn't (seem to) belong to Facebook anymore.

▲

dvtkrlbs an hour ago | parent [-]

I mean the foundation is still mostly governed by corpo

▲

RobotToaster an hour ago | parent [-]

Isn't that true for the linux foundation?

	▲	asmor 27 minutes ago \| parent [-]
		To a degree. But the corporate interest is spread across enough organisations that it's much harder for the Linux kernel to reject a patch solely because it's good for business, whereas a lot of corporate open source projects - even those with an OSI approved license - will actively refuse to merge code that competes with their commercial offering or simply isn't submitted by a customer. Hashicorp already operated like this long before they switched to BSL. Unfortunately having a project owned by a foundation isn't a good indicator either, because I know of at least one Apache project where the entire membership is one company, the CEO is the project chair and code is sometimes just dropped into repos in one huge commit.

▲

LoganDark an hour ago | parent | prev [-]

How do you handle projects where the owner is part of a large community? Maintainers of very important or useful projects should count, right?