A question was raised, with everyone who touched that package or filed issues or PRs about it in the last 3 years mentioned, and in 2 weeks no non-retracted objections are outstanding?
(Basically, if there are too many caring about the package to get to an agreement, maybe it is not a niche package and it has a chance of substantial reviews in the first place)
I said what I said above, because you don’t need to be an organizational expert to see with your own eyes, that necesarily the individually percieved owerhead on smaller units is far less, and so is the mooting effect of that overhead.
And if there is an overhead that really gets into a contributor’s way, they can at least perceive a path to realistically get rid of it.
Non of that is possible in nixpkgs for more than 95% of contributors (at least) — and within reasonable time.
I’ve tried some things and my success rate was far less than 50%. So I decided not to bother anymore and redirect my energy (sucess induced endorphine rush while working on devos is close to 100%). That’s what’s happening.
I’m not saying that I would be a notable loss to the community, by any means. It’s just an ordinary perspective of an ordinary contributor.
Personally I was driven away by the attitude that we don’t need tests or they are just an unnecessary burden for large features to go in and the fact that apparently almost nobody cares about documenting their changes properly in the commit messages.
So I question: Do you actually want tests in nixpkgs or are those that want tests just those that are vocal about it?
Having tests goes both ways. It isn’t just having them it also means maintaining them. If someone comes by an drops a new package with a large test suite that is great BUT do you want to maintain that without being an expert on say a random data science package?
I imagine a standard having to more to say about what should be tested (probably actually a few different standards for different types of package) and ~how (technically, level of detail, etc.)
You see, were there smaller fedarated units that make up the Fedarate Republic of Nixpkgs, you’d had had a light time introducing proper testing rules in one subunit that was ripe for it.
And good ideas usually spread.
As a german, I know what we owe to federalism.
Ceterum censeo: → Peter Drucker & Stafford Beer reed’em up!
I think (hope?) that if it were presented as an RFC as per our current
process, maybe linking to this PR as implementation work, then the
community as a whole would have more impact than a few individual
voices, and it would have more chances of getting accepted.
Effectively procuring proper direction abiding by the highest (and most effective) inter-human relationship standards for a group of more than 7 people is almost impossible.
That’s what management litterature has to teach us.
Member States havn’t to be as small as that, but usually there is tacit delegation to trusted individuals happening in an open source community context, so homogenous groups of trusted individuals that pull together on the same side of the rope, probably would be a sufficient (social) splitting criterion for the Federate Republic of Nixpkgs.
Ceterum censeo: → Peter Drucker & Stafford Beer reed’em up!
Also, have you guys considered the fact that a Federate Republic of Nixpkgs creates a few naturally aspirable vacancies that currently do not exist?
Those new vacancies are meaningful and rewarding.
You can argue that people need paychecks to solve the problem as much as you like, but people in open source are not intrinsically motivated by monetary retribution. At least not if you want great outcomes in return.
Ceterum censeo: → Peter Drucker & Stafford Beer reed’em up!
Having tests goes both ways. It isn’t just having them it also means maintaining them. If someone comes by an drops a new package with a large test suite that is great BUT do you want to maintain that without being an expert on say a random data science package?
Is it actually a problem? IMO tests are just a way to make building a
package actually OK only when the package works.
IOW, if said random data science package is not important, then we can
just break the tests with unrelated changes without caring much — and
then the next person who’ll want to use the package will have to fix the
tests. Basically, the same thing as we do for packages that stop
building.
OTOH, if the random data science package is important… then missing the
fact that it stopped working due to the unrelated changes was bad and
something we would want to avoid. Making this visible before the
unrelated changes land is then a good thing, and can allow us to poke
the maintainer of that important package before landing, to fix the
thing.
TL;DR: I don’t think there’s any additional maintenance burden for
having more tests that would get imposed on people who don’t already
maintain the tested packages, at least so long as the tests don’t
significantly slow down automation by just being slow.
Which only gets noticed when a package gets updated and the tests subsequently gets looked at, or if the test is part of the tested set. I last touched babeld in 2020/09 and now it broke in 2020/12 and I’m not sure how I ever could have noticed without polling for it.
Many of the most famous and successful open source projects were developed or maintained long-term by paid staff. The Linux kernel is largely developed by paid developers (Intel, Red Hat, etc.). Red Hat employs a large number of the glibc, gcc, X.org, Wayland, and GNOME developers. Rust started in Mozilla (even though it became independent since then). LLVM was developed at University of Illinois at Urbana–Champaign and then was further developed by Apple (and now many companies). LibreOffice started as StarOffice by Star Division, was then bought by Sun and open sourced.
This ‘work for free’ attitude is a pipe dream for companies who only want to benefit from open source and not contribute back. But in the end everyone needs to eat, rent/buy a house, travel, see the world, go out. There is nothing wrong with open source as a hobby, but there is also nothing wrong at all with receiving compensation as one of the motivators. I’d rather see good compensation for developing open source, so that smart people write great open source software, than have them write proprietary software.
Back on-topic. I think there is a lot of less interesting work, were I think it would be great if we could pay people to do it. There was a fundraiser to get better error messages in Nix – not the most exciting work to do, but it benefits the community hugely. macOS support is often lagging behind, because we do not have a lot of maintainers on macOS, so it’s great that @domenkozar and others raised money, so that someone can be paid now to improve macOS support. There are some other areas where I think funding someone for several hours per week would be very beneficial (e.g. triaging CVEs).
Nothing wrong with getting paid, still you unfortunately absolutely misread my point, which is somewhat informed by HR research in compensation strategies.
Empowerment and meaningfulness score much higher on the Maslow Pyramid and are much, much more important motivating factors for an open source context.
NixOS/nixpkgs absolutly abysmally fails at this, especially at empowerment.
Breaking stuff up and creating enticing vacancies in the Federated Republic of Nixpkgs, is just a “simple” “solution”. Can’t help but to stress that again, against the odds of “drawing the fucking owl” around here.
Note, that my baseline assumption here is that people lingering around open source projects neither starve nor lack a place to sleep (referring to the lower echelons of the Maslow Pyramid).
Ceterum censeo: → Peter Drucker & Stafford Beer reed’em up!
I don’t think it makes sense for Nixpkgs to be split up. Nixpkgs is the integration point where many disparate strands are put together. A “distributed distribution” etymologically looks like a tautotology, but is in fact more an oxymoron.
All that said, we can and should try to get more developer mindshare so that there is less “fighting upstream”. I think this is the best path forward to make things easier.
NixOS/nixpkgs absolutly abysmally fails at this, especially at empowerment .
I strongly disagree with this, and I think it’s quite the opposite at the early stage: starting to contribute to nixpkgs is “easy” (even without a strong knowledge of the nix language, or patterns of the repo,
updating packages, packaging stuff, reviewing “small” PRs, etc. is pretty straightforward).
I got into the Nix community especially because I felt empowered without as much friction as in other places…
But then, I rejoin what @jonringer mentionned: past the initial excitement, and once the is no more learning (the Mastery axis aforementionned), most of the work gets repetitive and boring to some extent.
Hmm, so what do endeavours that do not distribute enough of some resource do to make things work for the field? Oh right, dualisation, where people get merely acceptable amount of X but have a chance to win big. Which might describe Nixpkgs dynamic pretty well… and maybe this is one more reason for me to oppose calls to give out commit access less often.
That would actually imply that splitting removes the big prize and thus could make things worse (nope, there is no infinite empowerment to go around once nobody cares about your work) even beyond the ton of obvious issues like having a Thing to run CI against, or having Hydra keep the project together or having some people who have a chance of doing cross-cutting work, or having cross-cutting work even possible.
We definitely have some to offer in NixOS/nixpkgs. But you haven’t proven me wrong on a lack of autonomy, which my point has been.
I’m aware reducing the prize is an issue in the concert of incentives and motivators. I’m inclined to think our bigger issue (at least at this moment in time) though is lack of Authonomy.
The prize is so big at the moment, sub-prizes (like spearheading the python/haskell/you-name-it) subsystem tend to loose prestige, at least at face value, which they shouldn’t.
I want to add, that in terms of prize and overall dynamics, there will be a difference between:
Erm. The only winnable prize we have is full write access, and being important for the work on a large subsystem gets people who actually ask for that there pretty quickly.
