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.
I think limiting the recognition to repos that reach some level of significance would solve a lot of the problems.
It would anger the smaller projects and fresh projects, but it’s the only way to avoid having people create hobby projects or portfolio-filling slop repos and try to claim it as civic service.
This reminds me of a trend a few years ago when I started seeing a lot of applications from people who listed themselves as founders of a charitable foundation on their resume. I felt impressed the first time I saw it but got suspicious after the 3rd or 4th. Then I realized that it doesn’t take much work to incorporate a charitable foundation and list your family and friends as board members. The hard work was actually raising and disbursing money. When I started asking for details about how much the organization did I got wishy-washy answers and a lot of changing the subject. This is why details matter and it’s not as simple as giving everyone who claims an achievement the same reward, however small the reward may be.
Any time you introduce an explicit incentive, however small, to open source work the unintended consequences can become a problem.
The Hacktoberfest incident is a good example: The program offered a T-shirt to people who had a PR accepted. The result was tens of thousands of useless PRs across open source repos and maintainers begging for the program to stop so they could stop dealing with useless PRs. https://joel.net/how-one-guy-ruined-hacktoberfest2020-drama
In a situation like this you can’t assume that the set of people and the type of work being submitted will remain the same as before the incentive appears.
> 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.
In a program like this you can’t optimize for the assumption that every participant is acting in good faith and contributing good work even if it’s not accepted.
If a program incentivizes opening PRs even if they’re not accepted, the result will be a lot of maintainer spam from people opening useless PRs. This isn’t a personal hypothetical, it’s what we observe any time programs try to incentivize open source work. See the Hacktoberfest drama of years past where the promise of a T-shirt led to spam PRs across GitHub https://joel.net/how-one-guy-ruined-hacktoberfest2020-drama
It’s not a separate topic. You have to structure the program so that abuse is disincentivized from the start.
In the T-shirt example if you left the program as-is but then decided that tackling abuse is a separate topic, think about what that would look like: Every maintainer would now not only have to read and close the spam PRs, they’d have to go file an abuse report for every single one of them. Now you’ve put even more work on the maintainers and created an additional burden of reviewing reports, all without clarifying the program to discourage abuse from the start.
This is why it’s necessary to structure a program clearly such that abuse-level or low effort inputs can’t easily claim the rewards.
I mostly agree here, but the other side is now maintainers will be aware that not merging a PR could financially impact someone. I don't know that that's a great system, either.
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.
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.
GitHub stars would be gamed immediately. You can already buy GitHub stars by the hundreds from spam services.
A better solution would be to require a written proposal which gets reviewed by someone who assesses against some criteria such as project age and other factors. Don’t make it too hard, but make it enough to stop the scheming individuals who think they’re going to start their own GitHub repo, set Claude Code loose in it once a week, and call it civil service.
> 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.
I must completely misunderstand the purpose of the German system of conscription. I thought the point was to train the reserve populace in relevant skills to defence and public functioning, not just to extract labour.
> I must completely misunderstand the purpose of the German system of conscription
Conscription would be compulsory enlistment for service. That is, the government selects you for the work and you have no choice but to do it. It’s a rarely used practice almost exclusively employed for military service.
The topic of this petition is civic service. Civic service is volunteer work done for the good of the community. Civic service work needs to have a direct public benefit, not simply claiming that it makes you personally better educated.
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.
I think the anti-corporate angle is a bit extreme as it would rule out a large number of projects that are widely used.
If the project is truly open source and widely used by the community it shouldn’t matter if it is or was associated with a corporation. Contributing to it helps the public who use that project too.
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.
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"