I guess I’ll wade in…
Something that needs to be state up-front here is that the community build process is under no obligation to do anything. People have thrown around terms like “unethical” or “passive aggressive” or “bad faith”. The community build serves one primary purpose: a massive set of regression tests for the Scala language itself. Its secondary purpose is to provide a mechanism by which a quorum of the broader ecosystem dependency graph can move forward uniformly and in a timely manner to cross-build on new Scala releases. There is no contract, implied or otherwise, that your project or your favorite project will be included, will ever be included, or once included will remain included. So if you want to sling mud, recognize that you’re doing it on very subjective grounds that were ultimately built on good-will to begin with.
Attacking Adriaan is the equivalent of yelling at the company who sponsors free food at a conference just because they are no longer giving you nachos. They’re allowed to do whatever they want. They owe you, me, and the rest of us absolutely nothing.
Another thing that needs to be understood is that inclusion in the community build is not free. Even ignoring the CI compute costs, it drains a very meaningful amount of effort from Seth and others to simply keep things current and up to date. If you aren’t involved in maintaining projects in the Scala ecosystem (and particularly if you aren’t involved in maintaining more than one such project), you probably don’t realize exactly how much time and effort Seth pours into chasing down bugs and build problems in the community build projects. The efficacy of this time and effort is entirely dependent on bidirectional collaboration with project maintainers, and it’s definitely not something that happens on its own. Also Seth is a human being, and frankly if the commit message on the scalaz removal had been “removed projects that I don’t feel like updating anymore”, he would have been well within his rights to do so.
In a sense, the CoC is simply a proxy for “has a community which is willing to engage with Seth in a civil fashion”. Certainly many members of the scalaz community are willing to do such, and have done such consistently over time. I salute all of you! It is beyond argument at this point though that certain very vocal and prominent members of the scalaz community most definitely do not fall into this category. If that’s the reason for the removal, then it is an ample one.
Attacking this decision on purely technical grounds is a fair impulse but it ignores the fact that there are some very real subjective, human elements to all of this. Elements which very much can and should be part of the decision making process surrounding any member of the community build. Do not ignore these elements. Particularly don’t ignore them if you’re going to bring up things such as “contributions of the 2 most skilled women” as major counter-arguments to the removal. That is certainly a very subjective, human element to this removal. If you’re going to raise it as a point, you need to recognize as valid the numerous non-technical reasons which likely led us to this place.
But nonetheless, there are technical points certainly worth raising here. A common complaint is that scalaz is a (still) a very widely deployed project. I think that’s pretty fair, and I myself work on a codebase which has been using scalaz for nearly a decade and is likely to continue doing so for quite some time. What’s notable though is the fact that the removal of scalaz from the dbuild graph actually had relatively little impact on the build as a whole. Nothing depends on ZIO in the public ecosystem, and comparatively little depends directly on scalaz at this point (beyond what looks like a large number of compatibility submodules). This is telling, because it means that scalaz no longer occupies a central position in the future of the Scala ecosystem, as it is not a foundational dependency of the current versions of most other things in the build. This speaks to what the future is likely to look like, and also the present reality of the ecosystem.
Of course, non-ecosystem (i.e. commercial) projects tend to lag significantly behind the broader ecosystem in several ways and for many reasons, and so I expect scalaz will continue to be a very important foundational project (particularly for older codebases) for the immediate and likely midterm future. This doesn’t necessarily imply value to the community build though, since commercial projects also tend to lag behind on Scala versions, and really their versions of everything. There’s comparatively limited value in the community build catering to the needs of these projects when doing so comes at a cost.
The final point would be whether or not scalaz and zio are uniquely positioned to stress corner cases in the compiler in ways that other projects are not. I’m unfamiliar with zio’s codebase, but I am intimately familiar with scalaz’s and how it interacts with the compiler and its various corner cases over the years, and honestly I doubt that it’s exercising anything that other projects aren’t already hitting. Scalaz used to be really the state of the art in pushing the Scala compiler (at least among non-Shapless projects), but it really isn’t that anymore. Arguably Scalaz 8 fits that description, but mainline stable scalaz (7.2 and arguably 7.3) most definitely do not. And why would they? Because of the central position that scalaz used to hold within the ecosystem, it remains fairly shackled to compatibility with older techniques, older APIs (such as Unapply), older ideas (such as scalaz.effect.IO), and such. That’s not scalaz’s fault, it’s just what happens when a framework ages. There’s nothing particularly novel in scalaz 7.x anymore (because all the major ideas have become ubiquitous in other projects!), and thus from a purely regression testing standpoint, it is almost certainly redundant with other things.
One way to look at this: if scalaz were not previously a member of the community build, would it be a serious candidate to be added today? The answer to this is likely “no”, even on purely technical grounds.
ZIO possibly has a much stronger claim here. I simply cannot speak to it.
Summing it all up… Presence in the community build is not a right. It is not free (for Lightbend) on several dimensions. As with all things, it is a value tradeoff with a lot of subjective and objective factors. It appears the value tradeoff is no longer worth it to Adriaan, Seth, and others. Whether that is due to the CoC (or lack thereof), past/present community issues, technical position within the ecosystem, or even just a synthesis of all of the above doesn’t really matter, and those of us on the outside are not in a position to judge.
