> Anyway, as it is, I've archived uMatrix's repo, I can't and won't be spending any more time on this project, and neither on all such issues [linking to all issues closed as invalid].
https://github.com/uBlockOrigin/uMatrix-issues/issues/291#is...
So it's really confirmed then. Very sad news.
Edit: there's also a glimmer of hope:
> Whoever is free to fork under a new name -- I may re-open and resume development in some future if ever I feel for it.
1. Copy-and-paste the repo, rather than using Github’s forking mechanism, because Github “forks” don’t have their own issues/PRs (being something more equivalent to multi-branch workdir collections for an upstream repo);
2. Copy all the issues over from the origin repo (manually, or by writing a script against Github’s API/CLI);
3. Sadly, likely lose all the original conversation on those issues.
These problems would be obviated if issues were just data files committed inside the repo — with any branch that contains the open issue file meaning the issue pertains within that branch; and any branch that closes the issue meaning that the issue is solved as of that commit. A fork developer could just fork the repo in the traditional fashion, and end up with a fork of all the issues alongside.
Does any git hosting service/software handle issues in this fashion, i.e. as a layer of web-chrome and backend indexing over files committed to branches of the repo (where you’d always have to be looking at the issues as they exist within a particular branch)?
For that matter, does any git hosting service have a sane high-level set of workflows for “forking” in the sense of creating a competing (or replacement) maintained-upstream-repo for people to contribute to?
1. Agree with the original author that a fork/take-over is the right thing to do.
2. Create a GitHub organisation for the project, where rights and repos and everything can be re-allocated/delegated as needed.
3. Make original author transfer his repo to this organisation.
4. Done. No more steps.
It also includes magic redirects for all requests to the old repo, including issues and also git-request, so down-stream projects won’t even have to know.
It’s really very simple, and it works well.
I think this is a clear deficiency of git and many other VCSs, which fossil avoids. It's clear that bug reports and commits will frequently cross-reference each other, so they should be tracked in the same system. Git only implements one half of the puzzle, leaving the other half up to others which ultimately facilitates vendor lockin.
You can enable issues on forked repo, and any forked repo may receive PRs.
Still, manual repository is preferable as deleting repo will delete also its forks created using Github interface (at least it was happening some time ago)
I haven't observed this to happen - in my experience, the first fork becomes the new "upstream" for all the rest.
Their point was that issues in the new repo are completely separate from issues in the old repo. A new issue created in the new repo will be issue 1, and to browse the old repo's issues you have to navigate to the old repo. If the old repo is deleted all those issues will also be deleted and history will be lost.
That's why they mentioned the workaround of using the Github API to export the old repo's issues and re-import them into the new one, which would not be needed if issues were git objects and thus trivially copied into all forks.
Perhaps the activity was slow, I guess you could call it "maintenance mode," but I've been using it all this time and uMatrix works fine in its current state, so all it means is that there were no new features being added.
It looks like the immediate reason for the repository being archived was somebody opening one issue too much.
Unless you have trademarked the name, you don’t get to reserve it for a rainy day, anyone should be able to pick up the torch and continue the project without having to start from scratch with a new unknown name.
gorhill stopped doing uBlock and passed it to others, who subsequently took it in a direction he didn’t like, so that he resumed maintenance under the name uBlock Origin (since the name “uBlock” had been transferred).
So this time when he stops maintaining a project, he’s avoiding the same thing happening.
> I will never hand over development to whoever, I had my lesson in the past -- I wouldn't like that someone would turn the project into something I never intended it to become (monetization, feature bloat, etc.). At most I would archive the project and whoever is free to fork under a new name. For now I resisted doing this, so people will have to be patient for new stable release.
1. https://old.reddit.com/r/uBlockOrigin/comments/i240ds/reques...
Contribution graph for the original uBlock project during this time frame: https://github.com/uBlock-LLC/uBlock/graphs/contributors?fro...
and now compare to the 'personal fork' that is uBlock Origin: https://github.com/gorhill/uBlock/graphs/contributors?from=2...
So if 'squatting' the name of your own OSS project is considered 'user hostile' then let this be a lesson to people considering giving up their project: the person you give it to may abuse your trust and the trust of the community in order to further their own agenda, in this situation it was all just pretty harmless petty drama but it might not always work out so well.
Random Github projects aren't organisations with funding and staff with rules and responsibilities to keep the project running, it's okay to archive the project and let the community decide what to do, giving the project to the first person who asks may end up achieving the same thing as archiving the project or it may come back to bite you in the arse damaging your reputation in the process.
Not a lawyer, could be wrong about this.
Trademarks don't need to be registered to be enforceable. Registration makes things easier for everyone by stating the registrant's intented scope of the trademark and makes a few things easier for the owner. However, the enforceability of a trademark rests on its awareness by customers, active use by the owner, and active defence of the trademark by its owners. uMatrix certainly is certainly a trade mark, however, the two latter criteria are probably not met.
I'm also not a lawyer, just interested in this stuff. This is not legal advice. And of course the details will be wildly different in different parts of the world.
Again, I don't know anything, but I'm surprised that uMatrix would count as having been "commercially" used. And as you point out, these two criteria probably wouldn't be met if the project becomes inactive:
> active use by the owner, and active defence of the trademark by its owners
It's also still used by the owner, as it's still listed in several extension stores.
Trademark protection also doesn't end over night. Trademarks are generally protected for a few years after the owner ceased to use it. Also, one should keep in mind that trademarks aren't primarily an intellectual property concept like patents and copyrights. Their main purpose is to protect consumers from copycats and fake products.
As uMatrix was distributed to users through the extensions platfrom, this is already sufficient to classify as commercial use.
μMatrix
Obviously "anyone should be able to pick up the torch" has the issue that the "anyone" may well be a malicious person who is seeking to defraud the users for monetary gain.
https://blogs.findlaw.com/free_enterprise/2017/05/4-defenses...
https://www.forbes.com/sites/oliverherzfeld/2013/02/28/failu...
You already have the right to copy all of someone's years of hard work, add a tiny patch, and pass it off as your own project with a new name. The very least you can do is give respect to the original author by allowing them to keep their original name.
Then there's potential for libel. Let's say you fork a project, keep the original name, and then pepper the project with Nazi propaganda. The original author is trying to get a job, and his resume has the name of the original project. A prospective employer searches the name and finds the new project (with the old name) full of hate speech. If he gave away the old name, a libel suit to change the new project's name may fail, and his reputation might be forever tarnished.
Case in point: keepass -> keepassx -> keepassxc, where both keepass and keepassxc are maintained and are essentially separate projects.