Rust Audio

Resignation from Rust-LV2 development

I guess it’s quite obvious by now, but I don’t have the time and energy to develop Rust-LV2 anymore that I once had.

Initially, I had the vision of a modular and ergonomic audio synthesis environment that is Open-Source and doesn’t restrict itself with metaphors to past technologies. Rust-LV2 was supposed to be one of the prime components of this environment, providing a common ground for communication and interaction between the modular parts. I knew this is an ambitious vision, but I had the time and the energy to pursue it.

Things have changed. Setbacks in my studies and a new job take most of my time and I’ve learned to make do with existing, restricted music technologies. I would still love to see this free audio synthesis environment some day, but the drive to develop is gone.

Therefore, I would like to resign as the maintainer of Rust-LV2. If somebody else wants to take that role, I’d be glad to hand it over. Otherwise, I might still fix minor issues as they arise but won’t drive any further development.

I must admit: We’ve managed to do quite a lot and there already are a handful of people working with Rust-LV2, which makes me really glad and I truly appreciate every single contribution, question or comment you’ve made. I especially thank @Prokopyl, @Yruama_Lairba, and @PieterPenninckx for their work. Maybe I’ll come back, but for now: Thank you and good bye!

That’s understandable. I’ve been interested in integrating LV2 support for baseplug. I want to use raw C bindings for it, but your work will definitely help me in figuring that out!

Hi @Janonard, no worries. In an open source project, volunteer contributors come and go as their other duties are less or more demanding.

Your ambitious vision is a multi-year project anyway and I think it’s shared by many people in some form or another. I’m confident that there will be some very cool projects built on rust-lv2 and who knows, one day, when you look back, you will realize that we’re close to the initial vision.

On a more practical side, in my eyes, the duties of a maintainer are “only” the following:

  • triage issues (not necessarily fixing)
  • review and merge pull requests
  • release a new version when it’s time
  • keep an eye on the dependencies and upgrade if needed
  • make sure it still compiles with the newest version of the compiler
  • hand over maintenance if needed.

That’s it.

I perfectly understand and see no problem in it if you don’t develop on the pace that you used to (I couldn’t keep up just reading your changes, so it’s rather the converse: I don’t understand how you could keep such a pace). The question for me is: what about the items I listed above? If it’s still ok for you to do all these things, then I think you can perfectly stay the maintainer. If not, I can help a hand just to start. I don’t feel familiar enough with LV2 and with unsafe Rust to take over maintenance in the short term (even in the limited form listed above), but maybe there are other candidates.

Anyway, thank you very much for your effort on this project! I think it’s really cool :slight_smile:

Thank you @PieterPenninckx :blush:

However, The key problem I see is that a maintainer should be available and react when something needs to be done. I can’t guarantee that I’ll be able to do so. For users, it’s annoying to depend on a project that is officially still maintained but where the maintainer doesn’t respond, and I don’t want to annoy anyone.


Personally, I hesitate to propose myself as maintainer, I’m not sure to be capable to do this correctly. It’s mainly because I don’t have experience in “managing” project with several people like this one. For me, it’s even the first time I contribute to another github project by implementing and pushing new functionalities.

@Janonard what you living is unfortunately very common. It’s frequent to have a change in our life so we can’t continue some hobbies.

Maybe you also encounter the same kind of exhaustion I encounter frequently when making personal project :

  • you are thinking about something awesome

  • you’re trying to do some experiment and proof of concept and get some encouraging results

  • you work on a prototype.

  • you encounter some difficulties and/or you see that you work take much more time and effort than you expect at the beginning.

  • you reduce expectation of your project to be able to finish the prototype.

  • Eventually, you obtain a more or less finished prototype.

  • you are finally bored, so you give up, and do something else.

  • Sometimes, months or years later, you come back to make the project better, and you start a new cycle

Thank you @Janonard for your development. As highly as I appreciate your contribution as well I can understand your reasons to resign from it.

Still I would like the development of rust-lv2 to continue. In my day job I am maintaining and managing software projects (mainly closed source, an open source project just is taking off) so I have some experience in this regard.

I for sure cannot guarantee 24h response all the time, but I think I could keep the lights on and react to issues and PRs, as well as contributing some stuff myself.

Another point is, that I am still maybe not new but at least not very experienced in Rust programming. LV2UI, the pugl crates and envolvigo were my first like serious Rust projects.

So I am volunteering taking over the keys to the repos and the crates, so that the development is not blocked, if there’s no other person willing to do it. The worst thing that can happen, is that I resign in – say – half a year. Then we would be back to the point where we are now.

1 Like

Thank you @johmue, but I now see that I should be responsible and stay as a maintainer in the sense of @PieterPenninckx’s comment. But if you like, we could share the duties of maintainership, as @Prokopyl and I did originally. Would that be okay for you too?

1 Like

Of course. Good to hear, that you don’t resign completely. You know the codebase far better then me. So maybe I can take a chance to get involved step by step.

Is there really a standard of 24h response time as open source project maintainer?
When I opened my first issue a few days back I did not even expect a reply to my issue within 7 days.