I’m curious of how a value statement would look like if it was entirely derived from existing practices. I have my own list but I’m curious of other people’s perception.
What are values that you see being expressed in the community?
i’ll have to go the bill and ted route…
and also a mantra of Mitch Altman - Wikipedia
be excellent to each other
3 Likes
One value I think is expressed by the community–on a technical and social level–is democracy.
On a social level, NixOS accepts contributions from anyone through GitHub. We can do that because Nix is so transparent: we can merge PRs from people we don’t know, with no history of contributions, because it’s so simple to check out their work and test it ourselves. We can vet changes on a technical level, so we have less need for a trusted “inner circle” of maintainers than a traditional binary software distribution.
The technology reflects democratic values because Nix’s remarkable transparency levels the field between maintainers and users. A user can write a Nix expression and install it on their system–and distribute it!–with no more trouble than to install an official package from Nixpkgs. In the same way, they can check out the Git repository, make changes to NixOS itself, and run that on their system with no more difficulty than an official release. I haven’t found any other operating system like this. I think this is something really special about Nix and NixOS!
17 Likes
I really like that, thanks for sharing it. It resonates a lot with what I am seeing as well.
2 Likes
I would say Pragmatism. Designing something that brings more solutions to existing problems compared to the new problems it creates.
3 Likes
Direction for a better common
To build on @ttuegel’s comment on the role of nix’s transparency – this may be the secret ingredient which has allowed this community to thrive for as long as it has with minimal technical and social governance.
To elaborate, tools and values have aligned around decentralization which makes for a positive-sum game, whereas reliance on single sources of truth would lead to divisive normative conflicts. Distinct from compromise, in which everyone somewhat loses, this often enables collaborators to achieve antithetical ends without sacrificing their own values. The resulting diversity of collaborators is this community’s greatest strength.
3 Likes
There is a concept (if out of scope, we can move it elsewhere) that I’d like to bring up. This comes up in multiple contexts and it seems to have some explanatory power.
Responsibility and authority must be commensurate.
Authority without responsibility leads to bullying and tyranny.
Responsibility without authority leads to stagnation and unfairness.
In Nixpkgs, someone repeatedly taking on a responsibility, eg: to maintain the set of python packages, eventually achieves some sort of authority over that portion of the project. The right person to make overall decisions about a topic should also be the person who is most responsible for it. This is not often stated so perhaps it helps to be explicit. When someone contributes, they are also implicitly taking on some responsibility for their patch or the package they maintain, or whatever it is. If a problem comes up specifically about it, there is an expectation that they would help fix it. It’s not a strict requirement, as we are all volunteers, but the expectation is there. This creates a bit of responsibility as well as some authority over that patch. This then forms the basis for larger and larger components and creates a way to make larger technical decisions. Our RFC process also reflects this in describing the shepherd team, where familiarity is often correlated with contribution, responsibility, and authority.
This team should be people who are very familiar with the
main components touched by the RFC.
I’ve seen organizations that would violate the concept, and it would often end poorly. Imagine being given an implied responsibility, but no say over how to go about accomplishing the task. On the other hand, imagine having authority about a decision, but no responsibility about the outcome. Both would cause harm to the individual’s ability to be effective and to the organization’s health.
This also subsumes the concept of democracy, or at least it represents a different simplification of the underlying concept. In a context were all involved have a similar responsibility, having similar voting power for an issue is an attractive point in the design space. When the responsibilities are massively different in scale it becomes more attractive to lend extra weight towards those responsible.
9 Likes
I think I broadly agree with that. Do you believe this applies to subdomains within an organization as well? I’m thinking about the Community Team RFC in particular: I see folks contributing time towards and taking responsibility for creating a welcoming community for as large a group as possible. Should this responsibility be matched with authority to make decisions in this domain?
A value that I’d personally like to be expressed is being focused on F/OSS software first and foremost.
7 Likes
What I both see and value, is having got accustomed to completely incompatible preferences of different contributors, and finding what to do together to mutual benefit anyway.
4 Likes
Or turned the other way around, people that do things, (generally) get to decide. The python and Haskell package sets are shaped quite differently and were largely created by two different authors. In other communities, there might have been some sort of central authority that would have decided how package sets should look like. The end result is a bit messier but it also lets us explore different routes, and take the language specificities into account. I’m confident that over time we will be unifying those.
2 Likes
Another aspect which I think we do quite well is that we are generally quite honest about Nix and the state of things. We are aware that there are a lot of papercuts, and avoid evangelizing Nix as the ultimate solution to everything like other technology communities tend to do. Almost to a fault.
3 Likes
Another way that pragmatism is being expressed is that we generally tend to go for “good enough”. Small incremental improvements where we have a consensus. Instead of the “perfect solution” that never materializes, the bar for contribution is set to “is it better than before”.
I don’t know if you agree but I see OSS being applied first already. A good example is how nixpkgs allowUnfree is disabled by default. The main contention point is over macOS if it should be supported as a platform or not. I don’t see a lot of the Free Software ideology as the project tends to be more pragmatic.
3 Likes
There’s a class of problems in administering a Linux system where people have historically been told “if you can’t bother to spend hours rediscovering the solution to common issues, then Linux isn’t for you.” I’m talking about figuring out the nuances of audio, making things work with Wayland, configuring hardware-specific features, setting up services, and the list goes on. These problems are so pervasive that to many people they characterize the experience of using a Linux distribution.
For me, NixOS is all about addressing these common issues as a community. We have a chance to meaningfully flatten the learning curve so people can use Linux who may have otherwise felt overwhelmed. I want to be able to hand a less experienced user a configuration.nix, they complete the install, and they have a working system that they can tweak confidently, knowing they can always rollback or ask the community if they get stuck.
Obviously, we’re not there yet but I think this is core to our values. At least, it’s what motivates me.
9 Likes
I have a feeling that as practiced now, we have an interplay of two things there.
First is a technical initial assumption (as much of configuration is possible is a function of clearly separable artifact, even if you hand-write configuration it makes sense to put the files into the same VCS and put them into store during build and symlink into place). In a sense, technically enforced values work slightly differently.
Second is «package all the things», or maybe [information hazard reference redacted] standard of notability: «you noted it, so it’s notable to someone». This is also important for the vision you mentioned, although it can take different forms in terms of the project (there are unending suggestions that Nixpkgs would better be split, and even known unknowns make the trade-off hard to predict)
1 Like