mirror of https://git.sr.ht/~stygianentity/bincode
104 lines
5.6 KiB
Markdown
104 lines
5.6 KiB
Markdown
# Bincode is now unmaintained
|
|
|
|
Due to a doxxing and harassment incident, development on bincode has ceased. No
|
|
further releases will be published on crates.io.
|
|
|
|
As crates.io, unlike many other language-attached package management solutions,
|
|
lacks the ability to mark a project as archive or remove the last maintainer,
|
|
this final release is being published containing only this README, as well as a
|
|
lib.rs containing only a compiler error, to inform potential users of the
|
|
maintenance status of this crate.
|
|
|
|
If you were considering using bincode for a new project or are looking to an
|
|
alternative to migrate to, you are encouraged to consider some the following
|
|
alternatives, as well as the many other great serialization format crates
|
|
available in the rust ecosystem:
|
|
|
|
- [wincode](https://crates.io/crates/wincode)
|
|
|
|
Bincode-compatible alternative
|
|
|
|
- [postcard](https://crates.io/crates/postcard)
|
|
|
|
Similar in spirit and structure to bincode, but a bit differently flavored
|
|
|
|
- [rkyv](https://crates.io/crates/rkyv)
|
|
|
|
Zero copy deserialization, honestly the best option for many of the usecases
|
|
that bincode was intended for, like serializing transient data for
|
|
intra-program message passing.
|
|
|
|
# What the community can do better
|
|
|
|
Several tooling factors have lead to bincode's maintenance status being a bigger
|
|
issue than it needs to be, including:
|
|
|
|
- crates.io not having functionality for marking a package unmaintained or a
|
|
process for the crates.io maintainers to transfer ownership of an abandoned
|
|
package to a prospective maintainer
|
|
|
|
In many other programming language communities such as haskell and hackage, or
|
|
python and pypi, when the last maintainer of a critical crate just walks away,
|
|
there often an in-band status that identifies that package as having no active
|
|
maintainers, and usually at least _some_ policy in place for the package
|
|
collection maintainers to intervene and transfer ownership of such a package,
|
|
allowing the community to assign a new maintainer to the existing package,
|
|
automatically pointing the rest of the ecosystem to the new sources with no
|
|
intervention required on the consumers part.
|
|
|
|
crates.io not having any such functionality or processes creates a pretty
|
|
massive pain point when the last maintainer does walk away, placing the burden
|
|
on _them_, very often an already burnt out volunteer, to select a new
|
|
maintainer. If the existing maintainer does not do this, the only current way
|
|
to continue maintenance of the package is to create a differently-named fork,
|
|
and then go through the massive hassle of not only convincing the entire
|
|
ecosystem to use it, but to settle in on one community preferred fork. This
|
|
creates avoidable tension when maintainers _do_ just walk away, with community
|
|
members being scared to make the fork themselves, both out of fear of the
|
|
amount of work getting the community to adopt it entails, and out of fear of
|
|
making the inevitable fork-fight worse by adding another contestant.
|
|
|
|
- crates.io not having visibility for its internal source control
|
|
|
|
Much of the drama that resulted in the doxxing and harassment was centered
|
|
around the git history being rewritten when the repository was blanked out on
|
|
github and moved to sourcehut. While this is a legitimate cause for some level
|
|
of concern that merits at least asking a question, it is disappointing that
|
|
the community is focusing on it so much when virtually none of the users of
|
|
bincode are pulling from the git version anyway, with almost all of the users
|
|
using the crates.io release. While the existing bincode releases are tied to
|
|
the previous history through the git commit reference cargo release's
|
|
`.cargo_vcs_info.json`, the cargo releases, which represent the canonical
|
|
version of bincode, are not fundamentally tied to the git repository at all,
|
|
and there has been a lot of worrying about _the wrong supply chain_.
|
|
|
|
We have faced many questions like "if the github is deleted, where can users
|
|
make sure they are getting the old version of the source code" that are
|
|
answered with "there haven't been any crates.io releases since the migration
|
|
and history rewrite, just bring in an old version with cargo and you'll have
|
|
it".
|
|
|
|
This could have been potentially avoided if crates.io and cargo provided
|
|
better visibility into their internal source control used for packing crates.
|
|
At the very least, a link to the source code browser on docs.rs from the
|
|
crates.io page for a given release could have made more users aware of the
|
|
fact that crates.io/cargo provide such internal source control, and a full on
|
|
source code viewer, or even better a version comparison tool, integrated into
|
|
crates.io would have made things a _lot_ more manageable while there were
|
|
still such questions flying around.
|
|
|
|
- crates.io metadata is not editable without performing a release
|
|
|
|
Much of this could have been avoided if the crates.io metadata was
|
|
independently editable and included a contact information field (ideally
|
|
something like githubs private email solution, where it provides a generated
|
|
email address that forwards to something configurable).
|
|
|
|
At the time of migration, bincode was nowhere _near_ ready for another
|
|
release, and being able to independently update the source code link in the
|
|
crates.io metadata and provide up to date contact information without having
|
|
to roll either a special no-code-changes release off of a branch that only
|
|
changed those things, or roll a questionable intermediate release with the
|
|
changes, both of which likely would have only raised more concerns from the
|
|
community, would have significantly decreased the developer burden of
|
|
completing the migration in a public and notorious fashion. |