Actions on ecosystem fragmentation?

[pacien]

Question

There's a perception that the NixOS ecosystem is becoming increasingly fragmented, whether due to governance disagreements, technical divergences, or experimentation with new approaches. Do you view this fragmentation as a significant issue for the project? If so, what strategies would you propose to address it and promote greater cohesion within the ecosystem?

Candidates I'd like to get an answer from

No response

Reminder of the Q&A rules

Please adhere to the Q&A guidelines and rules

[tomberek]

We value experimenting with designs and concepts, and folding successful experiments back into continuous improvement for stable components.
- https://github.com/NixOS/nix-constitutional-assembly/blob/main/values.md#stable-evolution-over-stagnation-or-chaos

Some fragmentation is value-add, and allows for people to explore new ideas and concepts. I see Tvix as a good example of this, exploring alternative hashing schemes and showing what is possible if we rethink many of our assumptions.

Some fragmentation is zero-sum (or negative sum) and can be harmful if it is done in an interfering manner. I would encourage any fragmentation efforts to maintain compatibility and encourage re-use as much as practical so that overall Nix adoption benefits from network effects or can be folded back in.

Fragmentation itself is not specifically a bad thing, but it can take different forms, good and bad. The question asks about strategies and actions to promote cohesion; I think part of the answer is that the SC should avoid trying to pick "winners", but instead provide resources and support for various projects because we don't really know up front what is going to be the best approach.

We focus our attention on working together on our shared goals and working separately in a non-interfering way when our goals are independent.
- https://github.com/NixOS/nix-constitutional-assembly/blob/main/values.md#distribute-decisionmaking-widely

[mschwaig]

Fragmentation because of novel or different technical ideas is great, because enables innovation and competition of ideas and approaches, which once an they are proven, helps us see the world differently. This is working well.

In some cases once issues have been ironed out somewhere out of tree, we might want to take those innovations in, as options, experimental features and maybe eventually as part of the default user experience.
I don't think we are particularly good at this, because that requires an overall direction and vision of where we want to go, and decisions in favor of one thing over another. These are absolutely things that the SC must provide at some stage.
Otherwise to users, the benefits of what we are trying to offer as an ecosystem, get lost in the complexity of picking the right experimental and out of tree pieces, and putting them together correctly.

The other driver of fragmentation, I think, is dissatisfaction due to social, interpersonal or project-management issues.
These issues and the rifts that they create hurt people on both sides of them, and can easily deepen or get out of hand, because burning bridges is easier than rebuilding them.
The SC formally delegating power and responsibility, and reacting to problems, should help address some of those issues.

It will also take a lot of effort from people on both sides of the issues, to find common ground, and find ways to work together constructively. Everyone will have to accept, that in such a large community, other people are going to see the world differently, a lot of miscommunication is going to happen, and sometimes decisions that need to be made are going to be made differently then they would have liked, personally.

[phaer]

I believe the social division on governance issues - I personally would not call it "fragmentation" just yet - will take time to heal.

I do think we are heading in a good direction with the statement on values, the constitution and now the SC elections. But (re-)building trust among each other and into new processes will not work quickly and require lots of negotiations of all parties involved.

From what I have seen so far, I am positive that we will be able get to a rough consensus on what the most urgent issues are among a vast majority in the community; and slowly move forward on most of them - all while continuing to iterate on our governance structures and see what works for us and what doesn't.
Especially if we continue to learn from other communities of a similar size, actively moderate to ensure a civil and open discourse, and have better escalation points if things go wrong than we did in the past.

---

I see technical "fragmentation" mostly as a net-positive for the community, i.e. I love how both lix and (cpp)nix got many great new features and fixes since the fork, often ported. I also like how tvix re-envisions parts of nix, be it as a research-project as a hobby or someday as production-ready solution.

The SC mission in my understanding is to decide what's official and to ensure that users have a clear understanding on what is and what not. IMO it's quite clear already that (cpp)nix is official and tvix and lix are not. So I see now need for change here atm; after all, being able to choose your own tools is one of the great virtues in this community.

Flakes, on the other hand, should be made non-experimental IMO. Or even deprecated if needed, but everything seems better than keeping it experimental forever at this point. As it stands now, Flakes are almost everywhere in community projects, but nowhere to be found in official docs. This is an instance of fragmentation that hurts us IMO.

Lastly, there's sometimes discussions about upstreaming i.e. home-manager to nixpkgs. I think such decisions should first come from the respective maintainers and then be discussed in detail.

[djacu]

Regarding community division, healing comes with open communication, quick and healthy resolve to disputes, trust building, and good amount of time for all of these to happen. Creating the Community Values, Constitution, and Steering Committee are the first steps towards healing and re-building cohesion and trust within the community.

Generally, I see new and experimental technical ideas as a net positive. Consider the evolution of software languages. The first generation didn't get everything correct. As new languages were developed, they took the good features of the past and built new features where the old ones were deficient. The practice of reproducible software (e.g. Nix) is even younger. Many new ideas will be improvements and show ways of doing things better. As long as we maintain a good compatibility layer and provide a good user experience.

[getchoo]

Do you view this fragmentation as a significant issue for the project?

Sometimes, yes. Other times, no

Since I first picked up Linux and got involved in the FOSS space in 2018, I've found fragmentation to be an inevitability. This can often be a good thing, as no one project knows what is best for everyone and it can push both the original team and those that split to innovate and improve their respective projects (like in the cases of OpenBSD/NetBSD, LibreSSL/OpenSSL, and Blink/WebKit). In other cases however, I find that it is a sign of failure from the original project, be it something technical such as maintenance, or in regards to the community with a lack of transparency, communication, representation, and/or shared values (some examples here include XOrg/XFree86, Jenkins/Hudson, and Nextcloud/ownCloud)

If so, what strategies would you propose to address it and promote greater cohesion within the ecosystem?

In the case of the former, I would actually encourage fragmentation. Choice is paramount to FOSS and included in one of our shared values. Users should be able to have options in what tools they use, and as long as other projects genuinely provide features and experiences that are much better for them (even if the community here may not agree) I don't think it hurts our community. It is a net benefit

In the case of the latter, I believe the obvious answer is to confront those failures head on. Projects should never be pushing people away en masse for things that can be (relative to fundamental technical differences) easy to solve by listening and taking action on feedback. I think this is being well implemented in our community now through the NCA and this election, and I hope it continues with the elected Committee. No one should feel unwelcome or not accepted in our shared spaces -- especially those of us who are most vulnerable -- and ensuring they are heard and know that their opinions are valid is the first step to that. If done right, I would like to imagine a situation similar to Node.js and io.js merging could end this fragmentation, so that we may continue working together in a community where all feel safe and respected

[roberth]

Fragmentation could be beneficial when it leads to more choice, more participation, more innovation.
However, it can also lead to division and worse interoperability.

I think this is a question for everyone who participates in these projects. We all want the best for our projects' users, so it should be logical to communicate and collaborate where possible. This can only be stimulated, not imposed.

Perhaps the formation of standards and specifications could be supported by the SC. This would provide many opportunities to collaborate.

[proofconstruction]

I have mixed opinions on this. On one side, I tend to agree with the "let one thousand flowers bloom" principle, leaving space for people to fork projects and develop in new directions. This is a powerful signal of a healthy open source community, and is a crucial component of Free Software in practice.

At the same time, our community is surprisingly small and sparse, with just a few dozen people doing the majority of the heavy lifting; when they leave, it hurts, even if we take some time to feel that loss.

One reason I'm motivated to pursue stronger governance for the Nix ecosystem is that I know we can "have our cake and eat it too": by developing procedures for coordinating effectively and respectfully, we can keep the door open for differing technical opinions while still working together in unity towards our common goals. This work starts with a commitment from each of us to honest and open collaboration, and to continued cross-pollination of ideas and approaches between projects. I think we've collectively already been doing a good job here, though I acknowledge we've stumbled at times. We'll get there, and we'll do it together!