Taking over maintanence of a stale project

Community
1

Hi, I’m in need for some advice and suggestion.

I’m currently maintaining ocaml-protoc-plugin. This project was sponsored by my former employer, but they no longer have the capacity to maintain the project. I’ve agreed with them that I can take over active development, but they prefer not to transfer the ownership of the repository.

I’m writing here to get some input on best approach going forward, as I really do prefer not to develop and merge PR’s directly on their repository (branch protection is not in place, but they do have a rule that PR’s should be approved before merging).

The options I’m considering:

  1. Maintain the project using my own fork. This fork will point back to the original (soon to be) stale repository. The old repository still have issue tracker, but I would prefer that new issues are opened on the “active” fork - or I will not see them.

  2. Create a detached fork (Already did that here. This has the advantage that it will not lead people wrongly to the frozen repository the people will less likely report bugs / send PR’s to the wrong repository, but this approach may be sending the wrong signal.

  3. …

Let me also take the opportunity thanks Issuu for having sponsored this and other open source projects and their contributions to the Ocaml community / ecosystem. My intention is not to remove any credit to them - but to find a more sustainable solution going forward for maintaining ocaml-protoc-plugin.

Thanks
/A

2

You’ve already updated the URLs in the ocaml-protoc-plugin.opam file. Your next release to opam.ocaml.org will change the URL.

There should be nothing else for you to do, especially since you are the predominant git committer in the project history. Your sponsor will keep ownership over their github namespace (which makes sense); you can continue on developing.

3

Yes, it is fairly common that projects that have lost maintenance have been forked and maintained by someone else on their private repo. I have seen this but I can’t come up with any examples of that from the top of my head.

Maybe there is an alternative option to not transfer it to you personally but rather some (new or existing) organisation? That way they can retain access to the repo while other people can also contribute. Or transfer the repo to your account and then fork it for Issuu, so they can still keep a fork around.

But then again, if your repo is just declared the designated successor and you change the URLs to point to your version in new releases on OPAM I don’t think it is a big problem. There might be some stray reports but migration to a new repo shouldn’t be too hard.

1 Like
4

I don’t know how they feel about it, but adding a link to the new repo in the readme of the old one + archiving the repo in GH would help. Anyone landing on that page from a google search instead of going through opam meta data would know they should not report issues against it.

1 Like
5

Thanks for the comments. I intent to create a PR to update documentation upstream to mention where active development is taking place.

Is there a preference for creating a detached fork or a regular fork (pointing back to the forked repo) in this case?

/A

6

I don’t know if there is a consensus about any of this.
I personally prefer a detached fork, I find it confusing when I land on the correct project (the new fork) to be nudge back to the old one by GH interface.

7

(Unfortunately it’s not possible to detach an attached fork AFAIK.)

8

If the forks is new, so no issues/prs to keep around, then you can delete and push the same code under the same repo name as a new project.

9

If you choose a detached fork, please link back somewhere to the original repository. It is often useful to dig up older issue/pr discussions.

And thank you for working on and maintaining ocaml-protoc-plugin.

10

It’s possible to open a support request to detach a fork.

1 Like
11

Alright it worked. Sharing the reply I got, since it looks like a template.

Hi Lukasz !:wave:,

Thanks for reaching out to GitHub Support!

I have detached that fork for you, which means it is now the root of its own fork network. Please note that this approach may not be guaranteed in the future.

Forks are usually created to iterate on ideas or changes before proposing them back to the upstream repository. We have found that in most cases, a fork is created as a separate project from its upstream repository, and commits are not merged into the upstream repository.

If you would like to maintain a copy of a repository without proposing changes to the upstream, take your work in a different direction, or maintain distinct versions, you can follow these steps:

  1. If you have already forked the repository, you can detach the fork by following these steps: Detaching a fork. This will guide you through the process of turning your fork into a standalone repository and avoid the need to create a support ticket. The newly created repository will no longer automatically sync with changes from the original repository. Please note that the new repository will not retain any of the issues, comments, child forks, or other metadata that may be associated with your current fork.
  2. Alternatively, you can duplicate the repository via the command line by following these steps: Duplicating a repository.

I hope this information is helpful. Please don’t hesitate to reach out to us again if you have any further questions or concerns.

1 Like