The Future of SuperCollider Development Efforts

Development
1

Hi all (and while I am posting, this has been discussed among a number of us),

As many of you already know, there has been a vigorous (and at times contentious!) discussion of Supercollider’s future, process, and governance in various threads. At our developer meeting this weekend we discussed what we had heard and participated in and determined that it is time to find a better way forward.

Regarding development efforts, those of us at the meeting today especially took to heart the actions and perceptions of the ‘developers’ of SuperCollider. ‘The developers’ as a concept comes up in a few places in this forum, and we think is important for the survival of this software that representation better mirrors the user base. This should reflect not just racial representation and gender expression but all development expertise and contribution levels.

To be clear, most developer meetings have a few people show up consistently. And we all support SuperCollider the best we can with the limited person-hours available to us. This weekend, we had a couple more people join, and it was very helpful to see and hear how we can all work together better and take extra steps to make this a more welcoming aspect of our community.

For immediate next steps, we want to reset and consider what the primary development effort for SuperCollider looks like. For a couple of us who are often deferred to, we plan to take much more of a back seat in this effort. We want to support and help a new group of development leaders for this project. A community that brings in a more diverse background and experience levels gives more energy to a project. Many of us came into helping SuperCollider development as students and early professionals, and we encourage people who want to make SC better to chime in here to start and organize what SC development and maintenance looks like going forward.

Those of us who are now participating aren’t disappearing. We also know maintaining the status quo isn’t benefiting anyone at this point, and all anyone needs to do is read through the threads about ideas for SuperCollider 4 or funding/governance models to see that even with a small group of people’s best intentions, the current model isn’t working.

A number of us have reviewed this message and think this best represents the intentions of the current group. Some of us may clarify more personal intentions in the thread as well. Our most important message is this: no one here wants to tell people what they can or can’t do with SuperCollider and its development, and we want to work together to make this group larger and more diverse in every aspect. The current approaches don’t have to remain at all - let’s use the actions of the last few days to consider how to reset and move forward better!

24 Likes
2

Feel like that really needed to be said, thank you to all those involved!

I did have a few questions that perhaps someone could clarify? (something came up and I couldn’t make the meeting).

I think most of SuperCollider’s users base are musicians who have no interest in coding (beyond serving musical purposes) or software development (could be wrong about that but seems reasonable?). Should they? And if they are to be involved in the development, what role might they do?

Isn’t that what has caused the current issue (growth of scope combined with no modules/separation between core and addon)?

I’d love to be involved, but the things that I think need improving (gradual typing and some form of modules/namespace) require editing the language files. I have some C++ experience but never in a professional setting, and whilst I would need someone experience to review the code, I could contribute something… but I cannot for the life of me understand any of the pyr* files and I’ve spend hours reading them. It has been mentioned that very few people know what is going on in there. So is it really the time for those familiar with the code base to be stepping back?

To try and throw something actionable out there… here is a speculative plan

  1. Trim the sc class library down to its core essential parts (removing things like patterns and most ugens), and have that follow a strict code style, removing class extension and anything that breaks encapsulation, to serve as an example for…
  2. Throw away everything in the lang/ directory and start again implementing a module system so that supercollider can be flexible without taking on the burden of creep, and with some form of type system so we can have good immediate errors, and auto complete/correct.
  3. Release SC4 as a minimal functioning program (with no support for previous versions).
  4. Tooling.
  5. Begin re-complimenting things like patterns as separate modules.
2 Likes
3

I’m happy to participate within the limits of my abilities… even if that were to mean helping with documentation / facilitation…

One important order of business is to determine whether there needs to be some new structure/process for moving things forward or if the current structure is fine…

3 Likes
4

I really think that the distinction between coding for music and coding for development is quite fluid (especially in an environment which already involves coding on the user end). I didn’t come to SC thinking that I’ll be developing it one day. But as I built more and more projects in it, I started coming across “wouldn’t it be nice to have feature X” situation, and eventually became involved in the development.

Neither me nor Josh intend to step away from the project altogether as part of this transition (this is also expressed explicitly in the original message). This is about making changes in leadership (and that even might be too strong of a word, I don’t think any of the current devs consider themselves explicitly “leading” the project).

FWIW I myself don’t have much insight in sclang’s C++ implementation, my contributions were mostly in other parts of the project. There’s plenty of work on variety of levels :slight_smile: for those willing to spend time to contribute.

I appreciate your initiative.

I think that this thread is better suited to discuss the future development leadership and people’s involvement. Once this moves forward, and with some new people “in place” (more or less), the discussions about the actual functional development would be more productive.

And I want to underscore that really, truly, everyone who has experience with SC and is willing to spend some time to contribute is invited to the table here.

5 Likes
5

Thanks Josh, really appreciate this. It’s something that’s been on my mind for a while, and I’d like to share my thoughts.

I’ll provide some context, and then where I propose we go.

To be clear, I am not attempting to force this idea on the Project, but I think proposing something might help us get going.

Reaffirm/Review the Code of Conduct

I think the first thing we need to do is to reaffirm the code of conduct.

Is it fit for purpose? How do we plan to enforce it?

One of the main issues that comes up time and time again is safety. We have lost more contributors due to safety issues than anything else - we must do better.

Context

Decision Making

Our current structure is that of a do-ocracy: efforts are led by virtue of an individual spending the time and effort doing something, working on whatever they value most.

I believe this approach to organising ourselves has a large part to play in the current situation. I can’t speak for others, but in my experience:

  • I don’t feel that I have permission to make changes
  • I don’t feel that there is a process to get that permission
  • Being led by individual efforts, I feel that there is no collective direction, so larger scale changes are hard if not impossible to orchestrate.

The do-ocracy means that everything is on everyone as an individual, there’s no collective, and that’s tough.

I think we need to admit that the do-ocracy doesn’t work.

Ownership

Part of the reason I don’t feel I have permission is that I don’t have a sense of ownership - in the do-ocracy, I take ownership of the thing I’m doing if I’m adding something new, but what if it’s something that someone else wrote? I can’t take ownership of that, so I have to ask permission somehow - what if I don’t fully understand it and break it? How do I obtain a sense of ownership?

Membership

I get the feeling from the other threads that there is an issue surrounding membership:

  • Am I a developer? A contributor? A user?
  • Who are the developers?
  • Who can join?
  • How do I join?
  • Is there even such a thing as joining?

I think any way forward needs to address these questions.

Proposal

After, and only after, we have affirmed a code of conduct and related procedures, I think we can move forward.

Teams

The core proposal is that we create teams who are responsible for certain areas of the codebase.

One of SuperCollider’s strengths as a project (which is often viewed as a weakness) is that it has so many areas to contribute to. Are you interested in cross-platform gui applications? Are you interested in DSP? Are you interested in programming language design? Are you interested in writing great docs that help clearly communicate complex ideas? We’ve got them all, and I think that’s really exciting - there are so many ways to contribute!

The structure needs to model the project itself, so the teams I’d like to propose are:

  • sc-mods
    • Responsible for keeping our spaces safe
  • sc-ide
    • Responsible for the cross-platform GUI application: scide
  • sc-lang
    • Responsible for the language and interpreter: sclang
  • sc-classlib
    • Responsible for the core SC class library
  • sc-server
    • Responsible for the audio server and plugins: scsynth
  • sc-build
    • Responsible for the build system (CMake) and CI
  • sc-docs
    • Responsible for our documentation and tutorials

There are naturally areas of overlap between the teams - the idea isn’t to lock people in certain teams, but to communicate ownership, one person can be a member of multiple teams, for example.

When it comes to code review, we can set GitHub to require approval from anyone in the corresponding team - “approved on behalf of the sc-docs team by James S.” - this will help us gain confidence, and take the pressure off individuals.

I think the key thing to take away is that there’s nothing new in terms of the teams - all of these things have always needed doing, and they’re all equally important - I’ve just written it down.

Collective Decision Making and Ownership

The teams are about giving shared ownership.
The Project grants the team the power to make the decisions it thinks are in the best interest of the Project - no one individual is responsible, so no one person has to carry the weight.

Regular meetings

We already have regular meetings, but I think we can structure these differently if we have teams.

If we wanted to keep 90 minute meetings, then I’d suggest something like:

  • 60 minutes: teams in breakout rooms - team decides what’s most important for them and divides the work among the team
  • 30 minutes: all together - teams present what they’re planning to work on, asking for input/help from others

Transparent Membership

  • How to join a team - attend one of the meetings, join the breakout session
  • Who can join - absolutely anyone
  • What if I can’t code - come along anyway, your contributions are valuable to those discussions, and there are so many other ways to contribute to the Project that are equally valuable! But if you’d like to learn, see Mentorship below!

Mentorship

I’d like to propose that we adopt a mentorship approach, where anyone who would like to join a team can pair up with an existing member (or members) to help them learn and find their feet.

We have a lot of human knowledge dotted around the Project, it would be good to share it!

As an example of this, I believe the reason that the interpreter, and therefore the language, doesn’t get much attention is because very few understand how it works - I know I don’t feel comfortable making changes to that part of the codebase, pairing up with someone for a bit would really help build my confidence!
Or the pattern system - any time I see a PR for changes to patterns, I don’t understand enough to approve it.

But we also see a lot of people who would like to contribute code but don’t feel they have the programming skills - I’d be more than happy to pair up with anyone who wanted to learn some C++, for example.

The big issue with this proposal

There is a flaw with this proposal - it’s going to take a number of people to fill out those teams!
And I think that’s ok - if anything, that’s the goal!

We might start off with a small number, with some individuals in lots of teams, and that’s ok - the idea is that we have something we can grow, provided it’s safe. It must be safe.

A note on funding

You’ll hopefully notice that I haven’t discussed funding, or creating an official body, etc.

This is on purpose - I do not think we need these things.

To be absolutely clear: I will cease my contributions if money begins to play a part.
The Project will become about bounty hunting, and will bury itself in technical debt made by people who dip in and out to collect money - instead, we want to foster a community of developers who want to work together.

I am not in this for money. I’m in this to learn, to become a better programmer/colleague, to contribute to something larger than myself, and ultimately to make music.

TLDR

  • Make it safe
  • Make teams that have responsibility for certain parts of the codebase
  • Make joining those teams easy
  • Make the teams choose their direction, with input from others
  • Create opportunities to share knowledge

Shared ownership, shared responsibility, shared direction - shared goal.

Next steps

  • What do you think about the above?
  • What teams would you be interested in creating?
  • What teams would you be interested in joining?

For full disclosure, given my expertise and interests, I’d be interested in joining: sc-mods, sc-ide, sc-lang, sc-server, and sc-build.
And I’d be really keen to mentor anyone that wanted to learn some C++, and be mentored by someone on the sc-lang team to learn about the interpreter.

Sorry for the huge post, but this has all been in my head for a while.

Thanks for taking to time to read, and thanks for considering what I’ve written.

9 Likes
6

i think this is a great proposal and i-d be happy to be part of the sc-docs team.

2 Likes
7

Agree with a lot of what @jrsurge has written here, especially with regards to the code of conduct, ownership and project organization. My background is in music but I’ve been using SuperCollider now for almost 10 years; this was the first programming language I learned and the first open-source community I’ve been a part of. I’ve always thought it would be amazing to be able to contribute to this project but have always felt like I don’t have the right background/experience/knowledge to contribute to development and didn’t want to get in the way or make life difficult for the “real” devs who have important work to do…I know there exists a list of good first issues, but for someone who’s never contributed to a group project, has limited experience using Git, etc. I’ve never mustered up the courage to start tackling something on my own.

A mentorship program sounds super exciting as well - I wouldn’t have found my feet as a creative programmer without the help of mentors! Personally, I’d be happy to contribute to sc-docs and/or sc-classlib.

5 Likes
8

I think @jrsurge 's proposal is a terrific starting point. I’d be interested in joining sc-classlib and sc-lang (although baffled and unqualified for this latter ATM!) and perhaps sc-mod and sc-docs as well.

I would want to make sure that there is room in any structure for at least consideration of big reorganizations like @jordan outlines above, or reimplementing sclang entirely as @lnihlen was doing, or scrapping the IDE in favor of LSP/VSCode etc. I suppose these conversations could be had in the larger “general” group?

1 Like
9

First of all I applaud this effort. Kudos to Josh, James, and Marcin here (along with any other devs participating in the discussion), way to go!

Speaking only for myself, I would hesitate before joining a group like sc-lang or sc-server. My concern is about working in a group with such a potential for a large disparity between authority, responsibility, and capability. While in principle I support the effort to broaden the inclusion of folks with a diversity of knowledge levels and skills, I don’t think that such a broad group is necessarily empowered to make the right decisions about software engineering topics.

Certain parts of SuperCollider, such as the interpreter and the synthesizer, are advanced works of software engineering requiring detailed knowledge of a number of technological domains. Furthermore, developing, modifying, and maintaining software of such complexity with manageable technical debt requires disciplined software engineering. It is my opinion that this community has historically undervalued software engineering (as a distinct and different discipline from programming), which has lead us to the technical debt burden SC now faces.

I’ve spent over 25 years honing my skills as a software engineer. I’ve also extensively read sclang source code and am very familiar with interpreter internals. While I don’t think unconditional authority over any part of the language would be good for me or for the project (in fact that is one of the reasons I shelved Hadron), I am not enthused about having to argue software engineering or language implementation topics (particularly as bitterly as historically has been the case) with people who haven’t developed these skills and aren’t necessarily interested in developing them.

I think user feedback is great, and is invaluable for making software that is relevant and useful for our users. But I would prefer to explore a model commonly seem in open source that is one of earned authority. That is, a person’s opinions about what should be done on the software gain weight alongside their contributions to that software. This still allows relative beginners a path into contribution, and I’m supportive of anything we can do to bootstrap new members in. So take this as a big +1 to the talk about mentorship and coaching in the developer working groups.

For example, I find the LLVM development community to be pretty cool and supportive. I’m a relative newcomer with only a few contributions to my name. If I have a question or need help I can usually find it. But I don’t expect to have any authority over the big decisions that LLVM makes, and why should I? I’m still just fixing bugs and adding tiny parts of C++20 features. My goal right now is to be able to land a change in LLVM with minimal code reviewer feedback. I expect that will be my goal for years.

As an aside, a big portion of my day job is mentorship and coaching and I enjoy it greatly. One thing I found on Hadron is that I was approached by a few interested parties who wanted to become contributors. I invested a fair amount of time into each person, making sure they had a working build, answering any questions they had, etc. I never received a single contribution back to Hadron as a result. This was a drain on my time and emotional energy, another “drag force” on Hadron development. It lead me to question if my own time and energy investments in Hadron were wise. I learned that I think it is fair to evaluate open source contributors from a cost-benefit perspective.

All this might mean that my temperament and habits are not well-suited for being a SuperCollider developer, or open source development in general, which, well yeah, that’s been my conclusion for a while now. I don’t have the saint-level patience or unfailing kindness of the current maintainers. So, OK to dismiss this feedback as that. :slight_smile: Doing so even fits with my model of earned authority, which on the SC project, I have basically none.

As a parting thought, my authority model assigns a lot of authority to the maintainers, and I think their contributions will be essential both during and after whatever transformation this proposal brings about. I would urge you not to undervalue your contributions to this community by jumping in the “back seat” prematurely. I wish you, the maintainers, well in this regard.

Lucile

8 Likes
10

@semiquaver I was maybe hoping we’d get more of a discussion on the general idea of teams before going into the specifics, so I’ll maybe hold off on a detailed explanation for now.

In short, teams are to facilitate shared ownership and direction - having teams doesn’t solve the way those teams make decisions, or how inter-team dependencies work: we still need transparent and safe procedures for that.

The idea would be that teams aren’t fixed - they can be started and stopped:

  • The teams reflect the development efforts of the Project
  • Teams would ideally have a minimum size
  • If enough people want to work on something, a new team forms
  • If a team falls below the minimum size, it is disbanded and the Project stops putting effort into something it can’t sustain

Hopefully that provides enough of an answer for now? I don’t want to bias the discussion towards having teams if it’s not something we’re interested in.

1 Like
11

Many thanks Lucile, your input is greatly appreciated, thank you for sharing your thoughts.

I agree that we need to make sure that there’s a clear way to make decisions, and that the idea of having teams doesn’t address that.

I think we need to admit that we do not have the engineering capacity right now to facilitate what is being asked of us. All of the development efforts are currently being spent on keeping it all building - I’m not sure how many people are aware of this, but that is the reality insofar as I can see (please correct me if I’m wrong though).

So, I think a well defined organisational structure coupled with mentorship will help bring people into the Project, and skill-up those that are already here but don’t feel able to contribute. But maybe others disagree, and that’s ok, all ideas are welcome!

I don’t think our ideas are at odds with each other, but could maybe be combined.

Having teams solves half of the puzzle - how we organise ourselves - but perhaps something like earned authority could be a way to solve the other half: how we make decisions. I have some concerns about such an approach, but I’d really like to hear from others. I’ll take a step back from this thread for a bit to let others share their thoughts.

1 Like
12

I agree with @jrsurge’s ideas, but I also have to underline what Lucile wrote: The direction of development should be guided by seniority and/or experience within the project or development in general, as development resources are limited and should be allocated in a responsible and sustainable way. This does not have to be a conservative direction, but experience is probably the most valuable guide to how to do things, and perhaps when not to do things.

One thing that turned me off as a (former?) contributor was that it was hard to understand whose words made a decision final and whose did not. It turns out that SC does not have such people (although I am still not really sure), and while I can now understand why SC is structured that way, I actually found it not very inviting, because at the moment of a (first) contribution I am more interested in a final yay/nay, a why and maybe how on the contribution, rather than delving into the branches of arguments.
Instead of guiding a newcomer, I felt like I was moderating a discussion with people who have more power than me (because they still decide) but also don’t know their power/seniority on a topic, which created an uncomfortable atmosphere of power imbalance. This setup may work for people who tend to be more open, but people who struggle with social situations and try to avoid them are put in an awkward position here.
Specifying who the benevolent dictator is to guide the discussion would help a lot as a newcomer, at least for me. Managing the power dynamics and legacy code of a 25+ year old ongoing project is just one task too many for a newcomer.

Another question should be how to maintain and increase maintainability, so what should the coding standards be? For example, make tests mandatory or introduce test coverage?

My proposition

would be: Create a Dev Council that welcomes everyone and discusses the direction and gives power to the Benevolent Dictator(s) [please come up with a better name for this!] and the Council acts as the sovereign.
These dictators are responsible for coordinating development within their realms for a limited time, which would most likely include the areas mentioned by jrsurge. [Sorry for the offensive vocabulary.]

The Dictators will be responsible for organizing any discussion and feedback on implementation details, and respond (maybe?) within a week. I know this is a lot to ask, but with a rotation or split duty this might be possible.

The idea of teams seems to be more inclusive, but for me personally this is not the case because it increases my frustration as it becomes so difficult to come to a decision and such a decision making process can take some weeks or months and now I have to organize a discussion again - this is the reason why I stopped contributing.

However the SC decides to move forward, I think it is always good to talk about how to contribute! Torvalds once said “just pick the FOSS projects that suit your work and social style” and I think this is a good credo to live by - it will be impossible to make everyone happy, but the best way is just to discuss it in the community. I am really curious how the development of SC will continue! :slight_smile:

All in all, I would definitely like to become a more active contributor again!

PS: I also find the current state of discussion platforms a bit difficult - e.g. I would like to come to dev meetings, but they are only announced on scsynth.org and I check scsynth.org maybe once a month, so I always miss them and also picked up this topic only by chance.
I check GitHub almost daily and there is no post about dev meetings or this topic (since both platforms require an account to participate, it seems inevitable to make 2 posts in parallel?).
This topic should also be discussed w/ the GitHub community as well IMO.

@jrsurge : I would gladly take some CPP tandem sessions with you :slight_smile: I really enjoy this idea b/c with CPP I feel like some 2 hour google research could have been resolved in 2 minutes by asking an experienced dev “why is it like this?”

1 Like
13

IMO the topic of seniority is quite important, in particular with complex software like SuperCollider. One thing to always keep in mind is that seniority is (mostly) independent from age! I think we should try to keep “senior” SC developers in the boat. There is just so much tacit knowledge and experience that can be lost otherwise.

Personally, my time budget for open source development has become more limited and 99% of it goes into Pure Data and my personal projects. However, if anyone has any questions about scsynth or supernova internals, or C++ in general, you can always ping me on GitHub (Spacechild1).

Since we have talked about development models, I thought I may talk briefly about Pure Data, as its model is completely different from SC.

Generally, Miller Puckette has been the BDFL for 25 years. Every new feature or non-trivial change to the codebase needs to be approved and merged by him. However, since a couple of years we have a dedicated develop branch for trivial bugfixes (Commits · pure-data/pure-data · GitHub). There is currently a group of 3 people (including myself) who have write access. If a PR gets reviewed and one of us regards it as “trivial”, we can merge it right into develop. Also, since we are all seasoned developers who know the codebase inside out and trust each other, we are allowed to push trivial bugfixes directly onto the develop branch – without a PR or formal review process. We then make a PR with a list of all the fixes (e.g. stable development branch by umlaeute · Pull Request #2027 · pure-data/pure-data · GitHub) and Miller typically just merges it into master. It is a bit unusual, but I think it has worked great so far. Have a look at the recent history of the develop branch and imagine we had to open a PR for every single fix…

To be clear: I am not saying that we should copy what Pd is doing – it certainly is not how you would run an open source project with high stakes – I just wanted to give another perspective. In the end, every project needs to find its own way of doing things.

2 Likes
14

Blockquote
PS: I also find the current state of discussion platforms a bit difficult - e.g. I would like to come to dev meetings, but they are only announced on scsynth.org and I check scsynth.org maybe once a month, so I always miss them and also picked up this topic only by chance.

Pro tip: On any thread on scsynth.org (I do this specifically on the dev meeting poll and announcement threads), click on the “bell” icon on the right-hand side of the thread, then pick “Watching” from the list. You will then receive email for every posting on that thread.

1 Like
15

Developer meetings are also announced on the SuperCollider channel on Slack:

1 Like
16

Thanks so much for this initiative, it is really a good moment for that. For now, I just want to say that I’ll try to help and support wherever I can.

I am not on slack, so I’ll try to keep myself up to date here.

3 Likes
17

As I’m currently reading Daniel Pink’s Drive, I stumbled upon the – now already quite old – Agile Manifesto. In line with the thoughts of the book, it’s very much about making working and decision processes less frustrating – which I can relate to many posts in the recent debate. Although the idea comes from the business world, there seem to be bridges between the agile manifesto and open source, e.g., see:

Also, a quick combo web search shows a lot of hints, so the relation between the concepts is something people are thinking about. As I’m not a professional programmer, maybe I’m just repeating discussions some of you are very familiar with, but maybe there’s something in it worth to be considered.

18

First of all I want to express my gratitude to all the developers for the years of work on the project :slightly_smiling_face::pray:

I also like the move towards a structure that will allow more voices to be more easily heard and get involved. The only thing that kind of worried me was this part:

“‘The developers’ as a concept comes up in a few places in this forum, and we think is important for the survival of this software that representation better mirrors the user base. This should reflect not just racial representation and gender expression but all development expertise and contribution levels.”

I believe that the only thing that matters in terms of the relative authority in a development team is competence. I don’t see how racial identity or other expressions are relevant in any way unless there has been bias in the team that excluded people based on such characteristics which are not relevant to the competencies. That is to say that of course we should be careful to correct any bias if present (I have never seen any evidence of such bias in the SC community personally) but never try to enforce representation based on identity characteristics as this is not a correction for bias but an introducing of bias.

In general, I loved the mentorship suggestions and I would support @lnihlen 's suggested model of earned authority in conjunction with clear opportunities for “gathering” such earnings. For instance, I have been coding with SC for 20 years and I can most probably contribute to the sclang portion of the project to some extend. Maybe clearly designated “TODO’s” tagged with a skills level to enter that “earned authority” ladder would help me to get in when I have some time and do some work that will give back to this project which I love :slightly_smiling_face:

4 Likes
19

There’s a preponderance of evidence supporting the notion that “merit-based” systems that ignore the existing biases in our culture are actually more biased against underrepresented folks than are systems that try to address systematic inequity. We need systems that are aware of and try to address racism, classism, sexism, homophobia, transphobia, and the rest. I strongly oppose a “merit-based” proposal. Who decides that “merit”?

What I was proposing was a “contribution-based” system, where folks with a prior history of strong contributions to the software would have more authority over that software. To be clear, in this system, I personally have no authority.

This contribution-based system presumes a couple of things that I’m not sure SuperCollider has:

a) a group of senior developers with widely recognized authority over the project who would:

  • make final calls to resolve disputes
  • set overall technical direction
  • decide when to extend that authority to newer contributors and when to revoke it
  • do the enormous amount of work to identify tasks suitable for beginners, and render them in a format that can be consumed by those folks

b) a large group of motivated volunteers who are willing and able to work their way into the senior group

c) a healthy code of conduct team keeping everyone safe

As a senior dev, it takes more effort to identify and properly document a “good first issue” than it does to just fix it. Technical debt skews this bias even further in the wrong way, because of all the “baggage” the senior devs have to explain to a newcomer before they can write a single line of code. The tech debt o SC is so bad that, for a newcomer to C++ programming, I would guess it will take at least a year of time investment from more senior people on the team before that newcomer begins to produce more work than they consume in support. Attrition on OSS is brutal. How can they be sure each newcomer is worth the time? That’s time they could have spent developing the project, or even lowering the tech debt or scaling the support systems to make it easier on the next newcomer.

As a junior dev, particularly one without much prior experience, there’s a lot to learn and a lot of time investment before even one line of code lands in the repository. How can they be sure that investment will be worth it? My first view of SuperCollider dev was watching two senior devs resign due to burnout and abuse. I think that told me all I wanted to know about SC dev, which is why I started developing “SC-adjacent” projects,

The technical debt harms SC in another way here. I don’t think SC is a great first project for junior devs. The C++ code in particular is a disorganized, under-documented, antiquated mess. Yes, dealing with code bases like this is a part of the job, but not the part of the job I would typically advise junior people spend their time on. I want my impressionable junior devs to spend time on code bases that inspire them to even more discipline and best practices. I want them to internalize the message that with the right structures, clear documentation, and low tech debt we can move mountains. That is not the SC vibe.

If a junior dev had their heart set on this code base I would advise them to bias their work towards respecting the senior devs time. Don’t show up whining on the forum about how they aren’t making it easy for you to contribute. Dig in and get stuck and spend time frustrated with things and reading 15-year old stack overflow posts in desperation. That’s the job and that’s the learning experience.

I think even if we end up with a different governance model progress on (a), (b), or (c) would be great for this project. It’s ironic that there are so few senior devs left that the community doesn’t even understand how much trouble SC is in as a project. Like, it takes a certain amount of software eng experience to see the red flags but they are all over this one.Ya’ll are teetering on the brink and you don’t even know it. Makes me sad.

3 Likes
20

I don’t think SC is a great first project for junior devs.

I don’t think anybody expects an audio programming environment to be a good place to start for junior developers. In practice what I have seen a lot with Pd and SC is that people start to learn C or C++ by writing externals/plugins and once they become comfortable they might start hacking on the core.

The C++ code in particular is a disorganized, under-documented, antiquated mess.

Let’s be clear which part of SC we are talking of. What you are describing matches my experience with the sclang codebase, but I wouldn’t say the same thing about scsynth and supernova. Yes, scsynth is written in an antiquated C++98 “C with classes” style, but IMO the codebase is pretty small, organized and not too hard to understand once you know the overall architecture. Actually, I have the feeling that scsynth is the one part of SC that will survive the longest. The one thing I totally agree with is the almost complete lack of comments; that is really unfortunate. (To everyone reading this: always document your code as you are writing it – your future self and fellow humans will thank you!)

1 Like