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
Wtf. I super disagree, and find it inappropriate, and probably would even if i agreed. Speechless, really
2 Likes
I can confirm that what Nathan is saying is something I heard personally from multiple people. The lack of response on this is one of the reasons I left the project.
1 Like
This is an extremely important topic, but this is maybe not the best way to solve it… Flamming people here will not solve it…
What if we selected a group of independent people for doing conflict management/ombudsman/awareness team? Off course, it is extremely necessary to talk with the current dev teams about what they found about this.
- Should we create a conflict management/ombudsman/awareness team?
- Yes
- No
- Something else
0 voters
So many parts of this discussion really sadden me, to be honest. And I feel like it has gotten into unproductive territory. I’m shutting down further comments. If another admin feels a need to re-open them, that is fine. But otherwise I think this is very far from the OT.
7 Likes