Announcing community projects

• May 10, 2023 - 20:26

What are they?

Community projects are issues and features that are posted in the Community panel of an upcoming release project on our GitHub repository. These are tasks that the internal team won't get around to implementing for the forthcoming release, but which are still valuable inclusions that we would rather not to postpone to a later release. They'll be chosen because they're relatively manageable to implement, and won't require the dedicated attention of our internal development team.

Update (15 June 2023)

We now have a dedicated space for Community Projects in GitHub, where you can find all the available projects, and see which ones are currently being worked on and by whom. If a project is picked up by someone, we can then also assign it to one of our upcoming release projects.

Screenshot 2023-06-15 at 11.54.38 am.png

Who can do a community project?

Anyone interested in contributing to MuseScore's code can take on a community project, so long as you have a GitHub account and agree to follow all of our code guidelines.

How does it work?

When you find a project you'd like to take on, simply leave a brief comment in it so that we know you are willing to work on it. Participating in our community projects is done on a voluntary basis, but we will offer anyone who agrees to undertake a project:

  • Design support from one of the staff designers
  • Technical support, code reviews, and testing support from one of our developers

You can also suggest your own ideas for new features or improvements by raising an issue with the feature request tag, and our internal team will do its best to help you bring your idea to fruition.

Our aim is to support you in contributing improvements and features for MuseScore that will not only benefit the product, but will also leave you with the great feeling of having made a positive difference to an app used by millions of people worldwide.

For questions about community projects, please reach out to us on our Discord channel. @bradley k, @Peter Jonas or @cbjeukendrup would be more than happy to answer any questions you have.


This is great news, very happy to see something formal in place. And a nice-looking list of initial projects.

I haven't set up a build environment for MuseScore 4 so I haven't done any development myself beyond a few simple bug fixes I could manage just via GitHub. That may change, we'll see. But I'm definitely willing to help as I can for people wanting to get involved. I have a pretty extensive knowledge of the code base inherited from MU3, but am not very up on the new code.

In reply to by Marc Sabatella

Some of those critical projects have been sitting vacant (unassigned) for some time now. This was announced yesterday, but the formal structure has been in place for weeks. Obviously, most interested developers would already have github credentials and be aware of of this structure. I am concerned that community development isn't what it used to be. I'm not a developer and do not have the time or skill set to engage in that way.

In reply to by cfirwin3

It may have been in place, but it's a totally new structure that long-time developers would not necessarily have known existed. I for one had never seen this page before the announcement, and I follow things more closely than most. So actually, it's pretty safe to say that this is new info to most of its intended audience.

It is of course true that much of the momentum the developer community had prior to the start of 4.0 development is not there at the moment. This is unfortunate but shouldn't be surprising, since MuseScore 4 was mostly an "in-house" project, and it was more difficult for the rest of us to find ways to contribute outside simple bug fixes. I don't think anyone was particularly happy about that state of affairs, but most of us understood and accepted the reasons.

What this announcement shows me is, things have settled down and the doors to more significant community contributions are open again. And for the first time, there is some clear direction and processes in place to facilitate this. So, it is a welcome first step in re-engaging with the developer community, but I do expect it to take time.

In reply to by cfirwin3

Hi there, thanks for your comments. Marc is correct that we have now had to move the features we offered for community implementation out of our 4.1 project, as we have now entered the stabilisation/testing phase for this release.
But your comment prompted me to do a bit of re-organising in GitHub. Please see the update in my message above. Essentially, there is now one central place where we keep features designated as "community projects". You can more easily see here what is available, and what has been taken up by someone. Also, we can then assign projects to releases once we know someone wants to work on them (or alternatively, if we have the resources and nobody expresses an interest in an important project, we can remove it from community projects and work on it internally).
Hope this makes sense, and thanks for your contributions!

In reply to by bradleykunda

^This is a response. I have been waiting for someone to respond in this way for quite some time. You explained the reasoning, provided an adjustment and addressed the potential for an alternative outcome on important matters, which is reassuring.
Great leadership and engagement here. And thank you for your reply!

Do you still have an unanswered question? Please log in first to post your question.