Plagiarism Cohorts

Land-grabs occur often in open-source, as they do in any new market. There is a proliferation of free resources, that are taken by first come first serve, then slowly consolidated by the efficiencies and capital of monopolistic forces, into eventually a controlled market, which the timespan and regulations can forbade for a while, until a repetition, revolution, digression, or ejection occurs.

The monopolised consolidation is ripe to happen in Rust right now, as its maturing beyond its pupa form of its initial land grab.

Many (most?) contributors to Rust (the language and the wider ecosystem) are not paid employees; they are volunteers developing and maintaining crates in their free time.

Straight up demanding that they put more work in is not only rude, it’s also far disconnected from reality.

Too many low-level crates are still at 0.x.x and unstable - #4 by H2CO3 - community - The Rust Programming Language Forum

This is endemic, and probably requires a sea change in how we treat open source developers to resolve.

Too many low-level crates are still at 0.x.x and unstable - #2 by derspiny - community - The Rust Programming Language Forum

After a while you start to get a feel for which packages are better and will recognise which authors consistently produce high quality stuff.

Too many low-level crates are still at 0.x.x and unstable - #38 by Michael-F-Bryan - community - The Rust Programming Language Forum

Node.js had its land grab by decentralised forces through 2010-2015, then in 2015 the most-popular-first plagiarisers arrived which addressed the stewardship issue.

For those new to this, these are people who open their package manager, sort by most used first, then one by one for however many months or years it takes plagiarise everything under their own brand, monopolising attention and consequently sponsorship and contributions into one coherent brand, which funnels a positive feedback loop and leaves indie developers behind as fringe.

This is just like how it works in real life with any market - freely available property commences with decentralised claims of ownership and investment, and then is routinised by the efficiencies of centralisation by whoever can pour enough existing capital in the market to monopolise it, who then up the barrier to entry by managing expectations, creating a long-tail that replaces the initial rising tide, eventuating a controlled market with whoever else (if anyone else) that became monopolies, in which the only game left is by their own rent-seeking.

Unfortunately, people don’t recognise that MIT does not permit plagiarism - they think MIT and Unlicense are the same thing, but good luck sueing and competing for title of asshole of the year.

The only way to beat the plagiarism issue that I’ve come up with, and tested with talks with other major open-source original workers and other plagiarised authors, is by establishing plagiarism cohorts, that is accepting the issue is unavoidable in a free market and can only be mitigated / improved upon, as such, establish cohorts which plagiarise everything back, such that the same package is implemented by a dozen of so cohorts, which operate on different terms and technologies - returning consumer choice, and property rights and empowerment through unionisation.

For instance, right now in the Node.js world, the current lead plagiariser is breaking compat with CJS and legacy node versions apparently. This has spawned demand for alternatives.

Such differences of alternatives could be modelled on such things as:

  • only support latest node.js version and esm
  • support all node.js versions and esm and cjs and deno
  • funding only the cohort leader
  • funding all contributors of the package, including the original authors
  • acknowledging only the cohort leader’s brand
  • acknowledging the brand of all contributors, and the original authors
  • licensing with MIT
  • licensing with Parity
  • licensing with IcePick
  • allowing any github issue to stay open
  • closing github issues after certain inactivity
  • closing all github issues unless sponsors

Once we have cohorts, then we have the offering/portfolio/leverage/power to negotiate our rights back, as together we meet the minimum barrier to entries and competition, and can offer consumers competitive choices.

2 Likes

I’ve been trying to keep an eye on Rust, and have even written some here and there. But it’s been tough, especially as my medical issues had me scrambling to catch up on the work that pays the bills.

A lot of early Rust people were former Node people. There was a lot of mindshare from npm to Cargo, for example, and a number of folks pushing async and HTTP for Rust came over from JS.

A lot of lessons were learned. But I get the feeling Rust critical mass formed before the “sustainability” issue became a public thing, rather than a fixture of private conversation.

Rust is really caught between worlds. On the one hand, most rust code is written by individual unpaid contributors who would like to be paid. On the other, the well-known path to getting paid to write rust runs through employers, who are thought to be more numerous if there’s wide availability of permissive code. The latter view is more popular although there is a healthy minority of copyleft and “nonstandard” licensing on crates.io.

there is certainly some interest in splitting the difference, but current solutions have various defects. LGPL is theoretically a compromise license, but the linking requirements are too onerous in rust and it’s perceived to be too anti-employer. In practice MPL is the compromise license but it’s not very good

I’ve been going through this exercise for some of my own libraries lately. There are no good answers. I have been toying with crafting some exception to weaken some other license, but none of the popular licenses are a good base so that might just be confusing.

1 Like