Idea: a document that relinquishes control of my modules

Development
1

I want the modules I’ve been laboring over to outlive me.

Or even, I want them to continue being useful to people even after I’ve, say:

  • lost interest in working on them
  • become fully committed to something else
  • become unable to write useful code
  • (you get the idea - stuff happens)

Now, ideally, when I felt any of those things coming on, I could anticipate that fact and find someone to work on, and turn over the keys to someone else (though, I admit I’m not actually sure how that would be done).

But sometimes, stuff happens suddenly. Or I just lose interest, and just don’t do it. Whatever. In that case, I want a “dead man’s switch” to, at some point, become activated, so that, without me having to explicitly pick someone, whoever cares to can pick up my code and UI and keep it going, however they please.

My current thinking is that, if I haven’t made even the tiniest of updates to my VCV-related GitHub repo in twelve months, I’ve dropped it and I want someone else to pick it up.

The interesting thing, who has to believe that has taken place. So far as I can tell, the people this document needs to convince are:

  1. The VCV Community.
  2. VCV the organization, so that it will continue to build the modules when this new person asks, and respect that this new person is allowed to.
  3. ???

This should, I believe, be a document in the repo itself, much like the LICENSE.md file.

Thoughts?

6 Likes
2

I have been thinking much the same thing for a while now.

I am thinking one year of inactivity is not such a good idea. Currently I am pumping out modules on a regular basis, but I imagine it won’t be long before I slow down significantly. A one year or more hiatus does not sound crazy.

What about if the trigger for official abandonment is a critical bug or VCV version change that requires code work to preserve the plugin in the library. If no response from me within 6 months, then VCV / the community can consider it abandoned and someone can take over plugin maintenance.

I have thought about putting a document in the repository, but it would be nice to get acknowledgment from VCV that that would be recognized as legit. Perhaps this calls for an inquiry to support.

5 Likes
3

How about just sending a notice to VCV to declare you are OK (and the conditions) that anyone interested may take over? That would then declare the legitimacy, and put said intent document in the repository, That should do it I think. Also add the ‘we received your request and will honor it’ notice (or whatever constitutes a positive) from VC into said document with date and who sent the positive reply.

2 Likes
4

I’ve been thinking about this issue as well. My thoughts are a along the lines of a “declaration” document in the repository stating the requirements:

  • A period of inactivity (1 year? Year and a half?)

  • Contact needs to be made and a response time deadline set (A month? 3 months? Half a year?)

2 Likes
5

oh yeah, also a good idea

6

So in surge land we have a team for this reason but it’s definitely hard with rack. I have 4 pull requests out to fix abandoned modules where if the person pressed merge and added a line to the library the arm builds would fix

I had chatted a while back about a somewhat more radical approach with a person here (who I won’t name). Which is to have your module “belong” to you and a volunteer team. That team would have write access to your repo and could submit to the library and you could do it today. Then set up rules however you want

Because the problem isn’t just you move on and we don’t know, it’s forking the repo moving the code changing the actions

I know it sounds crazy - like why would you just give 10 GitHub users write access to your repo. But we’ve learned in surge if you use just a smidge of discretion about write access it works fine. Folks here are by and large wanting to do the right thing.

But we concluded that the demand for such an effort was low so decided not to do it - I still think about it though

But yes as seen by the modules without an arm port and the speed of rack2 ports this is a problem indeed.

3 Likes
7

I would never allow someone to take over my branding without my permission, so I would never ever post such a document.

I have actively given permission to @robert.kock to so this with my old modules, as it happens. Something with was almost trivially easy for me to do.

Would VCV change their rules to allows such a “last will and testament”? I don’t know.

8

This isn’t really a solution for everything, and it certainly isn’t a deadman switch, but I suspect we could get a lot of the benefit for very little effort if we each try to find a “buddy” who is willing to co-maintain our repo. They are like the Vice President (in the USA) who instantly becomes President when that person is no longer able to serve the role.

Any controversy about who is in charge of updates is left to each project’s repo owner. You can choose at any time to add/remove people to your repo’s write access list.

Right now, the original owner of a repo can post a note in their plugin’s GitHub issue (for example, mine is 733) to request that some other specific person/people be allowed to also submit plugin updates.

All we ask of VCV Rack would be to treat the other designated people the same way they treat the original owner of the plugin.

3 Likes
9

I agree don. Pick someone you trust and give em access to your repo and tell the library thread you’ve done so. Solves 99% of the problems

3 Likes
10

@DaveVenom Sure, I mean, whatever criteria sounds right to you. For me, I’d just have a yearly calendar entry to “touch the VCV Rack module”. If I’m still capable, but not interested enough to do that, maybe it’s time to free it up.

@fractalgee, @baconpaul, @Squinky - I completely agree that a person-to-person (or person-to-pre-selected group) handoff would be superior.

But life can take sudden curves that might make that less likely than not. I could:

  • Suffer a stroke, making me incapable of explaining to anyone about the modules. Not to mention, the people looking after me not caring enough to do it.
  • Get a neurological disease causing me to forget I ever made them.
  • Lose enough sight that I can’t code anymore.
  • Die suddenly. Stupid bus!
  • Become incredibly successful at (uh, something fun), leading me to be invited to party in Venice and the Azores so frequently that VCV Rack completely slips my mind.
  • Start dating two hotties half my age. Really, would I be thinking of VCV Rack then? I mean, you all are great, but uhhh… :slight_smile:

I have no reason to think any of these are particularly likely, mind you (especially the last couple). But my wife was a geriatric care manager, and some of the stories she experienced (someone, once a brilliant scientist, now unable to recall his email/contacts password so he can tell his friends he’s slowly dying) put the fear in me. Not to mention, the haunting threads on this very forum, of beloved tools no longer available solely due to the lack of interest, just a couple of hours of attention away from being restored. That would be a sad, cruel fate for these unpaid labors of my love.

Of course, even if we create a path for this, that’s no guarantee that someone will take up the mantle. So be it.

I now think of this as like a POLST; I’ll probably never find yourself in a position to need it, but if I did, “past me” would be really glad I’d set it up.

I agree, though, that getting signoff from the VCV powers that be is the first step. I’ll point out this thread to support.

Thanks all.

7 Likes
11

Let us know what they say!

12

Thank you for caring about your users!

Yes, good idea.

Yes. Call it “AdoptionPolicy.md” and in it say something like:

“In the case of it being more than 12 months since the last commit in this repository, and an inquiry in a GitHub issue has not been responded to in a month - I hereby grant the right to another developer, to fork the plugin, and submit it to the VCV library. In the manifest author shall be ammended with the new developer name, and repository URL’s changed to the new location.”

The only thing you need to think about is, if you have any CC-ND licensed files (e.g. artwork) in the repository. Either change that to the same license as the code (best), or grant an explicit waiver in the text above.

I’m very glad you’re thinking about it!

Yes, send a link to VCV in the plugin issue queue, to the above mentioned AdoptionPolicy.md file.

I belive a while back, when it was discussed with Andrew, he said that it basically comes down to him wanting to respect the developers wishes. I don’t think any rules need to be changed.

A co-maintainer is always a good idea.

Yup, there’s always the bus factor.

2 Likes
13

Yeah in early 2022 I reviewed all the surge stuff and made sure there was nothing which was “only me” in the flow. It took a day or two. If bus occurred the project could continue inasmuch as there’s a second (and third, fourth etc in most cases) person permissioned for everything weve shipped except the crappy BaconMusic plugs at this point. The code was all permissioned properly but some of the automation was not, which is mostly what I cleaned up

Good practice.

With all these things it’s easier to find a real person and just chat with them pre bus too, which is why I think dons suggestion is best. Find a buddy today and draft them in. Heck even have them do a point release for you to make sure it works even if it’s just a help string on a param

3 Likes
14

Don’t you dare speak that way. I dearly love Glissinator.

2 Likes
15

I made all my modules MIT licensed in hopes that it would simplify things in the future, should others want to take over development or make their own offshoots. I know it sacrifices any control on my side, but it has the benefit that my code is now free as in beer.

If VCV were to adopt some sort of official policy, I think that would be really cool. It could help prevent another ARMageddon, where half of the modules in VCV go black because of some change to the main codebase that devs who’ve moved on have no interest in addressing.

16

Want write access to the repo and to try a release? :slight_smile:

17

Sure, LOL!

18

Marc did something although I’m not sure what it means

afbeelding
afbeelding1368×338 41.3 KB

3 Likes
19

Basically it means if I get hit by a train and am not around anymore, for example, there’s something in place so that someone can continue to officially update the plugin and keep it in the library. I’ve also added that to the LICENSE.md file* in my repo (it’s currently in the ne2 branch), but it will be rolled into the master when the update to my NoteEcho module is completed. *[EDITED]

This entire thread was full of good ideas and was a nice discussion, and it made me reflect on things, and that’s how I decided to proceed. With MindMeld and Geodesics, @steve and @pyer are part of those repos, respectively, and so they could arrange to continue their support, but in Impromptu I’m the only person responsible, and in the interest of the users, this discussion did resonate with me.

Any developer truly interested in the continued use of their modules and everything that users invest in, time-wise and such, would serve the Rack ecosystem well if they did something similar. Obviously there can be many different approaches, but at least the one I took here is something :slight_smile: .

12 Likes
20

for an easy solution - couldn’t you just say what your wishes are in your license file?

1 Like