What would be a polite / correct way to take over a mostly abandoned open-source project?

Question

There is this popular open source project that maintains a language specification.

The original maintainer also maintains most of the programming-language specific libraries like Ruby, JavaScript and Python. Other members from the community have contributed other programming-language implementations, such as .NET, C++, Elixir, etc.

That latest changes to the specification were done six years ago, and, although the specification did not officially reach an official v1.0 release, this specification was taken advantage of in most cloud-vendors CLI tools.

Since that time, the original maintainer ignored pull requests and issues and never offered feedback despite repeated attempts to contact him through his various projects.

Last year, I assessed interest from the community and offered to maintain the spec and steward change proposals with the goal to bring improvements. Seemed the community was interested but I could not follow through due to time and priority constraints.

Recently, early this year, I committed to maintain the spec and steward change proposals going forward. With help from members of the community, we actually forked the various repositories and did the following changes:

• Rebranded the language specification to <popular-language> Community Edition.
• Created a process from which accepted enhancement proposals automatically generate the public-facing website.
• Gathered most requested changes, categorized them and initialized discussions with the goal to have the community vote and provide feedback.

At this point, I reached to all past interested members of the community. This was a clumsy step on my part as it was sometimes interpreted as SPAM. One piece of feedback I had from members of the community, though, was to know if this was a hostile takeover and if, indeed, we had tried to reach the original maintainer before working or our own fork.

That’s when the original maintainer chimed in and offered to continue working towards his original implementation. Although by this time we had broken the fork relationship, I actually published all the relevant changes we had made in our forks around typos to the website, modernized automated generation tooling, references to implementation libraries, etc. as pull requests.

This was one month ago and the original maintainer did not offer feedback any more. He did not acknowledge a simple question as to whether he needed help or more time or anything.

At this stage, I feel stuck.

On the one hand, our work on the "community" fork is effectively stalled. On the other hand, the original specification project does not appear to be maintained in a sustainable way nor with a steady-pace as was evident from the past six and half years history.

What would be a correct way to proceed forward with our fork without coming across as too aggressive and not alienate the community?

Answer 1

The proper way is to fork the project and to make it clear that the new project is a fork of the original.

In practice, this means that the new project should brand itself with a name that is distinct from the original project. Some examples of this currently in use:

• XFree86 vs. XOrg.
• OpenSSL vs. LibreSSL.
• GraphicsMagick vs. ImageMagick.
• Firefox vs. Basilisk.
• Jenkins vs. Hudson.
• MariaDB vs. MySQL.
• Vim vs. Neovim.

The new name may contain hints that the new project is forked or related (e.g. GraphicsMagick and ImageMagick both spell 'magick' with 'ck'; Jenkins and Hudson are both English surnames; and so on), but the new name should be sufficiently distinct, to avoid confusion and to avoid creating the impression that one is trying to mislead the 'legacy' users of the original project.

In general, one cannot really "take over" an open source project. The code is free to copy, modify and redistribute, though, so of course one can fork it and continue it in a new direction, at a new pace, with a new development strategy, and so on, if one wishes.

That latest changes to the specification were done six years ago, and, although the specification did not officially reach an official v1.0 release, this specification was taken advantage of in most cloud-vendors CLI tools.

Since it's a programming language, this makes clarity even more important. People that are currently relying on language X or implementation X in a production environment may well prefer the stable nature of X (stable in the sense that the spec is changing slowly) over new features that may be offered by X′.

Perhaps you will adopt a development goal to ensure that X′ remains backwards-compatible with X. However, when it comes to a programming language specification and/or implementation, ensuring full compatibility is often easier said than done.

Rebranded the language specification to <popular-language> Community Edition.

This naming scheme seems potentially problematic to me. Appending words such as 'community', 'professional' and 'enterprise' to an existing name X is often done when the same product X is released with a modified feature set or a different licensing model. Examples: Visual Studio Professional/Community, PyCharm Professional/Community, CloudBees Jenkins Enterprise, Red Hat Enterprise Linux, etc.

So, if you decide to refer to X′ as "X Community Edition", it's possible that some original users of X will be confused by this naming choice.

Related questions and answers:

Should I keep the old project's name in the copyright details after a fork?

Can you reuse a project's name, if the project is MIT licensed?