Many of the people involved in the repeated hostile behavior (including, in some instances, outright ageist discrimination) towards productive contributors, as referenced by @VIRTUALDOG and myself, remain active in the SC community and have suffered no consequences whatsoever for their actions. We can’t even begin to think about a foundation without confronting this.
I’ve thought this through and, once again, all signs point to a total rewrite being more manageable than a fork.
IMO the worst scenario is to loose brains due to absence of consensus. Disagreement is important and inevitable, however abandonment in the case of such a small community can lead to the fade out…
@nathan, it seems that you, @VIRTUALDOG and @lnihlen would like to propose a new version of SC from scratch, right?
I read on Hadron Postmortem — Lucile Nihlen a complaint about the way users and dev teams deals with novel propositions. So, why not to develop a new version privately and release it when it is mature enough?
I think that missing at least an alpha version of Hadron due to absence of support (financial, emotional, etc) from the community as a whole (devs and users) is such a terrible mistake…
For my part, no. I just propose SC fix its broken governance.
I’m not proposing it. I’m currently building it.
Nathan raised some important points about scope creep. He is totally right that lots of stuff can (and should!) be either thrown out or kept as third-party extensions.
Pd extended (a fork of Pd with “batteries included”) faced a similar problem 10 years ago. It was a huge project and the lead maintainer eventually burned out; nobody dared to take over and the project has been essentially dead for many years now. Purr Data followed its footsteps and I have the feeling that it will eventually meet the same fate…
Pd vanilla, on the other hand, is alive and well. It has a minimal core (some would say, too minimal) with a rich ecosystem and a really nice package manager (Deken). Now, Pd has its own share of problems with technical debt, but it is kind of managable and we are still able to make big leaps forward. For example, the upcoming Pd 0.54 release will have true multi-channel support 
Of course, it should be mentioned that Pd follows a BDFL governance model (Miller Puckette).
I think the lesson here is: if you want to build an audio programming environment, keep it as small and simple as possible, but provide a rich interface for third-party extensions.
Fortunately, there a exceptions. Pd has been supported by the IEM for decades and I don’t think they have any particular expectations. Finding a generous and reliable(!) institutional partner can be invaluable!
To correct the record, I have never indicated that the lack financial support was a barrier to development of Hadron. I’ve never asked for money, and in fact would not be able to work on Hadron for pay.
Just to add on, as the info might have been easy to overlook by my reference to your paper in the other thread (SuperCollider 4: First Thoughts - #291 by dkmayer): the SC community also got a lot by IEM’s support of your work (VSTPlugin), even if it was a “side-result”.
Some thoughts here, some super strong opinions as well, but I think it is also important for the debate:
One example of the risks associated with starting a project from scratch and the potential consequences can be seen in the case of Perl 6. The development of Perl 6 resulted in significant changes and incompatibilities with the existing Perl language. The magnitude of these changes was so substantial that the Perl community decided to rebrand the new language as “Raku” to differentiate it from Perl.
This experience highlights the potential trauma and challenges that can arise when attempting to build a framework from scratch.
Learning from such experiences, it is often advisable to consider strategies that help to mitigate potential disruptions.
An interesting aspect of the development of the new language is that it incorporated suggestions and feedback from the community. The language designers took into account the desires and requests of the majority, who often had specific SMALL changes in mind. However, as these individual suggestions were combined and integrated, the language gradually evolved into something different from what was initially envisioned.
Someone said at the time: "The Perl 5 community, meanwhile, is split between “fck yeah" and "fck you”.
Just a thought…
I just want to chime in to say that there are silencious lurkers like me reading this topic. Among them are probably some people asking themselves the same questions you are discussing and observing the situation with the same feeling of urgency that most of you share.
As is the case for most forums, people might feel (this is my case) uncomfortable to join the discussion for they lack a thorough recount of the whole situation and a better understanding of the project’s contribution process and dev practices.
If now is the time to really tackle the situation, I feel that it is important to re-explain clearly why the situation is blocked and how it happened. It looks like this could revive painful memories for some and throw gas on the fire if done improperly because of past conflicts / griefs.
Is there someone on this forum, external to the dev process, that followed the history of the project on the long term? Thinking about somebody neutral that could voice the different perspectives on project lead and dev projects that took place or never took place. It could be interesting for people like me who arrived late in the SC world to understand the different dev philosophies and tensions that arised from the work of all those who tried to maintain / improve this awesome pile of code.
I have been an active user of SuperCollider since the first symposium in Birmingham and have been closely involved with the language and its community ever since. I fondly remember how the symposiums, including the recent one in Boulder, provided a welcoming and vibrant space for our community to gather.
In recent years, I have noticed a certain shift in the community dynamics that has raised concerns for me. As a result, I have been less active on forums, which has limited my exposure to this evolving atmosphere. Also, I was interested in other things.
Anyway, I found it intriguing at the time when I learned that JMC (after his retirement, more specifically) and Tim, two prominent contributors to the SuperCollider project, decided to step away. It prompted me to reflect on what might have contributed to their decision, which I find unfortunate for various reasons. For example, Tim has started a separate fork to continue his development work independently (that is, he is an SC dev, just not on this fork) and JMC’s experience attempting to address very sensible concerns with the team that decided to adopt some bad source control practices, such as a tab vs. spaces (or something as irrelevant as this, with a backlash of “building a wall” in the source code history, etc). JMC was ignored, just as we mere mortals are ignored or confronted (for nothing) by some in the community.
Our collective growth and the continued success of SuperCollider rely on fostering an inclusive and supportive environment that welcomes diverse perspectives and encourages collaboration. But also, it requires a bit more social sensibility.
That’s my impression since you asked.
adding to this: many people mentioned that SC urgently need a new governance model. I think it is important that all devs (currents or not) share their thoughts on what model we should adopt. Moreover, people should make clear which kind of governance their are totally against to (e.g. Pd BDFL or business solutions), or tell even if they don’t care about this at all.
I know it can be also painful for devs to see users “poking their nose into other dev’s business”. But the main goal of FLOSS is to be used by users, right? In addition we are the main feedback providers and testing resource… so:
What governance model would you like to see on SuperCollider?
I have no stake in the future of this project and don’t see it as my place to comment on that.
Of developers leaving the project: Some of that is my fault. I regret this. Too little too late, and I don’t expect my apology to be accepted, but there’s been some tension lately around this so I at least want to say that… I know, I’m not that stupidly unaware… and, I’m not proud of failing at that time to deal with frustration constructively.
Of backward compatibility: Some history. SC1, I have no direct experience. SC2 was a completely different language (basically current sclang, minus a few syntax niceties were added in 3.x) – no backward compatibility. SC3 was a completely different DSP architecture – again, no backward compatibility (and here, I saw first-hand how that basically killed cruciallib – which was beautifully adapted to the SC2 design and, despite Felix’s heroic efforts, worked pretty well but never quite sat comfortably in SC Server).
Here, I think I’m with Nathan. There’s no way to fix what’s broken about SC without breaking compatibility. My gut feeling is 1/ go big and bold: something with radically new capabilities where the concrete gains make it worth switching; and 2/ don’t do it in 3.x (by the time you get up to 3.14, there should be some assumption of stability in the 3.x line). SC4 would be exactly the place to streamline and retool.
I personally stand to lose a lot from a backward-incompatible SC4, but obsolescence would be worse.
Of attracting new talent: I’ll admit to not having a concrete idea, but I’d point out that what broke me as a contributor was unit testing. When a low-hanging bug fix took 10-15 minutes, but it took an hour to write a streamlined, automated test that correctly distinguishes the earlier failure condition, and then the code review process nitpicked at the places that were (are?) awkward to handle in the test framework itself, I can imagine new contributors getting quickly turned off. Things may have changed; I haven’t been following github issues/PRs lately. But, back when I was still trying to contribute, I could see both sides: de facto, the standard was “you are individually responsible for everything in your PR,” and I experienced this as high pressure. But I could also see that dividing labor would just offload all the unit testing burden onto a small few devs and that would be unsustainable too. I’m not sure what to do about this. Boilerplate solutions for commonly encountered test-design flaws might help, maybe? Or maybe it’s just being done differently now, in which case, I’m happy if processes are working better. (I’m not saying btw that code review or unit testing should be weakened or abandoned – not at all, attention to these definitely improves the codebase – just that I think it was underestimated just how unpleasant that part of it was.)
hjh
Or maybe it’s just being done differently now, in which case, I’m happy if processes are working better
Actually, I have never written a single unit test for my PRs. I have only worked on scsynth and supernova, so maybe the unit tests have only been a thing with Class Library code?
Personally, what annoys the hell out of me when contributing C++ code is the enforced code formatting via clang-format - in particular the requirement for a specific clang-format version. I think this is a real hurdle for new contributors. To be clear, I am not against auto-formatting – on the contrary! – but I am wondering if there is a way to streamline the process?
Generally, I have seen a tension between enforcing good engineering practices on the one hand and developer convenience on the other hand. In a company you can argue that developers are paid to put up with this stuff, but in an open source project that is run entirely by volunteers this is a bit harder to justify.
One thing I do like is the rigid PR review process. This has been invaluable because it significantly improved the overall quality and stability of SC. Personally, I tend to enjoy PR reviews (both ends!) because I am interacting with people and possible learning things on the way – I am not just fighting a stupid machine. However, we should always strive to make the PR review process a pleasant experience – especially for newcomers!
Of course, it should be mentioned that Pd follows a BDFL governance model (Miller Puckette).
Just my 2 cents about this whole conversation, since I’m interested in open source and I find this quite interesting and constructive.
I know I don’t have any historical context here, as I’m new to SC but, from a sociological point of view, I think the BDFL point mentioned here is even more important than any technical decision.
Inevitably in these scenarios, the real struggle is not the work to be done, but the decision making process (aka what to do, when to do it and why).
I’m not suggesting a similar model here (as I’m not not suggesting it either), but I’d simply like to highlight the fact that having somebody in charge (with somebody being anything from a single individual, a committee, or the whole community) is kind of inevitable. It is strictly necessary in order to move ahead.
Having somebody (again, I’m not necessary thinking about a single individual) in charge also means that responsibilities are clear (without wanting this to sound ominous though).
At the risk of stating the obvious but, it’s going to be impossible to make everybody happy. And different ideas/proposals might even be as good and valid as each other, but the real issue here I think is not that.
In my view the main points are: what’s necessary for any of those to happen, what are the benefits/consequences of the specific work and who’s responsible for it.
Even just from this thread is clear that there are some divergent ideas (see full rework vs “small” improvements), and I’m not able to comment on any of those either but, I think at some point, in order to make progress on any of these, a good dose of pragmatism will be required (and again, I don’t mean this in a bad way)
I think I fall into that category. I’ve been using SC for over 20 years, encountered still SC 2. I started miSCellaneous_lib – at first privately – in 2007/08 but was never involved in general SC development. I have followed a lot of discussions and lively debates – to put it mildly – on the previous lists and on the forum.
My take is that situations tend to repeat themselves with different actors, driven by underlying sociological facts. The most ambitious developers are typically the younger ones – the old-timers rather want to preserve and slowly evolve things. Nothing new, ying and yang, progressivism and conservatism, however you want to call it, naturally two sides of one process. This can be more or less constructive in the overall outcome, in recent years it was probably a less lucky situation, but that could change again … It might sound a bit trivial but I think we all can take a breath and look at ourselves from the outside, our viewpoints are – to a large amount – given by where we stand in our lives.
As my possibilities allowed, I always wanted to give a forum to different voices and ages. In the mid 2010s I organized four one-day SC symposiums here at IEM Graz. E.g., I had also invited @VIRTUALDOG who held a talk. Maybe more live-exchange of thoughts could help in general.
I’ve been thinking about posting this for a few days now. It may be off-topic, and I tend to see this issue everywhere, so some people might find it irrelevant, but I thought it might be worth mentioning. I’m not a dev or particularly active in the community, so this should be taken with a few grains of salt.
With regards to comments from @nathan and @VIRTUALDOG about conflicts, governance and their treatment in the community, I’m interested in how diverse our community and the dev/mod teams actually are.
I’ve been to a few SC meetups and I have the impression that our community is not particularly diverse. The majority of people who have shared their screens at meetings I were at were white and male-presenting. This may have changed - I haven’t made it to a meetup in the last year or so - but it was certainly something that I (and others) have noticed. It’s also interesting that (at least) two openly queer people have left the project.
I don’t think this is the main issue, or the root of all conflicts, but in my experience a lot of conflicts are influenced by questions of diversity, and it’s worth thinking and talking seriously about them. The very active and vibrant Tidal community is, in my opinion, one worth learning from!
I know that the devs work very hard on a voluntary basis, and I am very very thankful for their massive contributions. But, I do wonder how we could be more welcoming and encouraging towards a diverse range of people, and if this would contribute to a more open, democratic and effective system of governance.
Well said. This is something I’ve struggled with for years and - to be frank - often feel somewhat lost re pushing the needle on. This is maybe worthy of a whole separate thread entirely, as it feels in a lot of ways that this is a deep underlying factor for a lot of these more organizational / aspirational conversations.
Something that I think may not be obvious to everyone, and that I think is worth ALL of us thinking about very carefully: I’ve met MANY non-white, non-cis-male, queer, etc. deeply invested and enthusiastic SuperCollider users over the years. Almost to a person, they have been fully disengaged with the mailing list, forum, and github ecosystems. I think we should all keep in our minds both the general social facts here - it’s well known that both music tech and programming online spaces as a whole are extremely unwelcoming to certain kinds of people, and as a result those people often simply avoid them a priori - and the specific ways that we (meaning: the people that are present in these spaces now) may be contributing to this, or not doing enough to combat it.
Just really straightforwardly: there are a lot of people that are not here, and there are deep reasons for this that are not just personal preference. This should be concerning for everyone.