For my part, no. I just propose SC fix its broken governance.
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:
2 Likes
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.
4 Likes
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.
2 Likes
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?
2 Likes
I have no stake in the future of this project and donāt see it as my place to comment on that.
1 Like
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
2 Likes
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!
2 Likes
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.
4 Likes
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.
1 Like
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.
2 Likes
We should also talk about the elephant in the room: there are very little women in our community. In the big SC user survey, only 5% (!) identified as female. (245 people participated in the survey; while this is not a huge number, it shows a clear trend ā which also matches my subjective experience.) Letās not forget that women make up roughly half of our population. Of course, this is a problem with programming communities in general.
Personally, I had quite a few - very talented! - female colleagues while studying Computer Music in Graz. For some reason none of them ā as far as I know ā actively participate in the Pd or SC community ā although they are definitely interested in technology!
3 Likes
I think the key is to try to create a single open community - to try to break down hierarchy and entice more users into viewing sc as ātheirsā. Just today a user used the language āI hope it will be implementedā for a method - perhaps they didnāt understand that they could participate directly in its implementation!
Another thought - I have female and non-binary friends on Mastadon who follow sc related tags - maybe some kind of outreach from this forum/dev-community ought to happen on social media?
Could not agree more.
Just to add one way that these things might be relatedā¦
I once saw a lecture about C++ (by one of the adobe devs, forget which one) talking about a related term, inclusivity.
Essentially, he argued that against rust, C++ wasnāt very inclusive, and couldnāt be to the extent rust is because it has many thorny edges and cases where the user can āblow their foot offā.
The point being, in rust, the discourse might look likeā¦
- person A: Iām trying to do this, what do you think
....some code - person B: This approach has some advantages, but have you considered
...some code, it has these pros and cons ā¦ blah blah blah
Whereas in C++ its more likeā¦
- person A: Iām trying to do this, what do you think
....some code - person C: this is outdated and dangerous, go learn about
some newer feature
Whilst person Cās tone might have been more considered, they are fundamentally correct as these things lead to poor dangerous software and a lot of wasted time.
Supercollider, whilst not as bad as C++ does have several difficulties that can lead users down paths where their code, and therefore musical performance, can easily fail or place unnecessary limits on their music. While the C++ community needs to steer people away from writing memory leaks and what-not, the supercollider community ties to help people write code that can scale with their practice, allowing them to explore new musical possibilities, whilst building pieces/instruments that are stable enough to take on stage.
My point is that, perhaps, software design influences community discourse?
And that, whilst all community members want to help, steering people towards writing sustainable code is challenging, as ultimately, we do not want to include (unintentionally) broken or otherwise temperamental software that can lead to poor experiences with Supercollider, or worse, wasted time or failed performances.
It is interesting that @jordanwhitede mentioned Tidal, being, of course, built on Haskell ā a challenging, but safe language. Rust is the other language/community that takes inclusivity seriously to the core of its design.
And whilst this has been about inclusivity of software-use and musical perspective, perhaps, by having a safer (or at least less fragile) software ā and thereby, more inclusive and accepting discourse ā,
we might attract a larger, and therefore, increasingly diverse user base?
2 Likes