I can think of sudo (https://github.com/sudo-project/sudo/graphs/contributors) which is maintained by just one person and is being used by every major linux distribution
SQLite won't accept contributions from outside the core team; joining the core team is an involved process, as they're taking extreme measures to ensure it will continue to be recognised as a work in public domain in as many jurisdictions as humanly possible. You can still support the project by paying them for their work (or by getting your employer to do so):
My understanding was that you could absolutely contribute without joining the core team, but you do need to file some paperwork to ensure that code can remain in the public domain. The need for the legal paperwork is that public domain is not a thing in multiple countries.
TL;DR: they have a company that legally employs every single co-author, to be able to sell you a Warranty of Title, just in case your company/jurisdiction/etc has a problem with public domain.
If you really want to dwelve into this, while the applications have plenty of cases let's not forget the underlying libraries that "everyone" depends on.
I don't have something nearly as popular as these other projects; but if you have a popular project, a potential employer might offer work hours for it to get you as an employee.
Further, as a contributor of some now popular projects with one other maintainer, I can say that I mostly do it for fun. My current employer gives zero-fucks about it but if a new employer were to use it to woo me away, I would jump in a heartbeat.
My employment contract specifically allows me to keep any rights that I do on my own time and equipment that doesn't compete in certain areas -- and enumerates those industries.
No payment, not a hobby, very little passion, doing it because the public needs it. (And possibly got started because, damn it, somebody had to write it / take over maintenance.)
Oh yes, I'm sure there are. I maintain a few; none are ultra-popular but some are kind-of-popular. And I am sure that others have had this sentiment before and wrote something which others now rely on, without being particularly passionate about continued development of that thing. And it becomes like a chore which you know is important to many people rather than just one or two.
There are many, people doing (good, valuable) things on PHP, however active people with deep understanding of the engine can be counted on less than a hand. (I contributed some small things to the engine and other parts in the past)
> It is stable and in use by distinguished frameworks and tools such as Mockito, Hibernate , Jackson, Google's Bazel build system and many others. Byte Buddy is also used by a large number of commercial products to great result. It is currently downloaded over 75 million times a year.
Absent any changes in a year, the copyright year shouldn't be updated. Otherwise what you're claiming is that the copyright term starts from a date after creation of the content, so it's getting artificially extended.
The change in question isn’t about going from “Copyright (C) 2023” to “Copyright (C) 2024” but from “Copyright (C) 1998-2023” to “Copyright (C) 1998-2024”. Thus your case doesn’t apply, it’s not confusing. What I’m saying is that as far as I understand, having “Copyright (C) 1998” and not changing it would suffice.
Yes, I read your comment as saying that having the starting year and changing it every year would be sufficient. Which it isn't, but I've seen it often enough elsewhere that it's worth calling out.
Starting in ~2008, the ones marked 'maint' and 'all' touch multiple files and don't appear to make substantive changes to e.g. cat. Since that categorization started, only 10 of the changes have been specific to cat.
To be fair, there are a lot of commits that just update copyright years or documentation. IMHO that's just regular housekeeping and cannot mean that cat was not "done" in first place.
This is a good answer. Especially in the light of the 2021 drama and the maintainer's benevolent dictator status. What happens when the community disagrees with a benevolent dictator's decision?
It would probably be easier to enumerate the small number of projects which have a larger amount of maintainers. I think the vast majority only have a few maintainers.
Good list. Sometimes the easiest way to contribute is to just donate some money, so that the existing maintainers can continue to focus on their work. OpenBSD is the "mothership" project for both OpenSSH and LibreSSL: https://www.openbsd.org/donations.html
Unfortunately I couldn't find any information on how to donate to these projects:
It almost feels like it's easier to list which fundamental projects have more than one active maintainer.
Many of the core library and tools are mostly finished and have very little yearly activity. How many maintainers does a project have if the last activity was one or two commits made or maybe just merged by one maintainer 3 years ago, and few more 5 years ago. Does it count as 2 maintainers, 1 maintainer, 0 maintainers? Does the "maintainer" from 5 years ago still have commit permission and how likely are they to get involved if some merge requests show up.
Even for active projects it's very common for 90% of work being done by one main maintainer.
> Many of the core library and tools are mostly finished and have very little yearly activity
Yeah. The ad-hoc, de-facto "Standard Library" for JavaScript, the "web", and fullstack web apps.
OSS ecosystem is sometimes so very "Down and out in the magic Kingdom" adhocracy like. Shame we haven't got the rest of the Bitchun' society's perks. :) hahaha!
Note that the situation will not be much better for closed sourced projects.
Sure, your vendor will probably fix bugs, but it may take some time until they find someone who has any knowledge of that codebase and survived last week's reshuffle, the re-org in spring and last year's buyout.
I don't know that it is better for closed source projects, but regardless open source has an escape hatch closed source doesn't. If something goes wrong, you can maintain it yourself, or fork it.
I've done it myself.
That one property along is enough if you want longevity, open source is always a safer bet than closed source.
In my case, I guess it extended the projects life by another 20 years.
111 comments
[ 43.7 ms ] story [ 643 ms ] thread- Lua (programming language): team of 3 - https://www.lua.org/authors.html
- openssl: 15 people - https://github.com/orgs/openssl/people
maybe also: sqlite, vim, nginx, redis
SQLite won't accept contributions from outside the core team; joining the core team is an involved process, as they're taking extreme measures to ensure it will continue to be recognised as a work in public domain in as many jurisdictions as humanly possible. You can still support the project by paying them for their work (or by getting your employer to do so):
https://www.sqlite.org/prosupport.html
TL;DR: they have a company that legally employs every single co-author, to be able to sell you a Warranty of Title, just in case your company/jurisdiction/etc has a problem with public domain.
How many maintainers for the other ones you mentioned?
Redis team consists of 8 people: https://github.com/orgs/redis/people
https://lwn.net/Articles/981559/
-do their employers recognize their effort and give hours to the side projects?
-they mostly contractors so can arrange their time accordingly?
-donations?
-or is it mostly a hobby done out of passion?
Further, as a contributor of some now popular projects with one other maintainer, I can say that I mostly do it for fun. My current employer gives zero-fucks about it but if a new employer were to use it to woo me away, I would jump in a heartbeat.
No payment, not a hobby, very little passion, doing it because the public needs it. (And possibly got started because, damn it, somebody had to write it / take over maintenance.)
https://github.com/Homebrew/brew#who-we-are
https://thephp.foundation/structure/
"Core Developers The PHP Foundation contracts 10 full-time and part-time engineers to maintain and develop the PHP language."
maybe less of a bus factor now with OSH approaching feature/speed parity and having more maintainers https://www.oilshell.org/
> It is stable and in use by distinguished frameworks and tools such as Mockito, Hibernate , Jackson, Google's Bazel build system and many others. Byte Buddy is also used by a large number of commercial products to great result. It is currently downloaded over 75 million times a year.
Did you know tools like uname [1] and cat [2] in GNU coreutils have essentially only had two contributors in the past decade?
[1] http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=histor... [2] http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=histor...
New editions of books have new copyright years, since they’re new books.
Same thing with code
Nevertheless I wouldn’t dare make any claim on this. Even in the presence of the Berne convention (https://en.wikipedia.org/wiki/Berne_Convention) the world is large and diverse.
"'cat -v' considered harmful" is an ongoing meme, but there's truth to it. http://harmful.cat-v.org/cat-v/
cat(1) concatenates files. Some software should be considered done.
https://github.com/eggert/tz/graphs/contributors
https://en.wikipedia.org/wiki/Tz_database
https://lwn.net/Articles/870478/
They discuss it, try to come to a compromise, and if all else fails, fork it.
Maybe it's not ideal, but then again, people seem to have a big problem when you have 'boards' running these projects too, so...
LibreSSL
Linux-PAM
OpenSSH
re2c
tzdata
zlib
Those are just the ones that came to mind.
Unfortunately I couldn't find any information on how to donate to these projects:
- https://re2c.org
- https://github.com/libexpat/libexpat
- https://github.com/linux-pam/linux-pam
- https://zlib.net
tzdata is actually maintained by IANA:
- https://www.iana.org/time-zones
They maintain the list, but someone has to package it.
Many of the core library and tools are mostly finished and have very little yearly activity. How many maintainers does a project have if the last activity was one or two commits made or maybe just merged by one maintainer 3 years ago, and few more 5 years ago. Does it count as 2 maintainers, 1 maintainer, 0 maintainers? Does the "maintainer" from 5 years ago still have commit permission and how likely are they to get involved if some merge requests show up.
Even for active projects it's very common for 90% of work being done by one main maintainer.
https://github.com/sudo-project/sudo/commits/main/
Yeah. The ad-hoc, de-facto "Standard Library" for JavaScript, the "web", and fullstack web apps.
OSS ecosystem is sometimes so very "Down and out in the magic Kingdom" adhocracy like. Shame we haven't got the rest of the Bitchun' society's perks. :) hahaha!
Sure, your vendor will probably fix bugs, but it may take some time until they find someone who has any knowledge of that codebase and survived last week's reshuffle, the re-org in spring and last year's buyout.
I've done it myself.
That one property along is enough if you want longevity, open source is always a safer bet than closed source.
In my case, I guess it extended the projects life by another 20 years.