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

  Bincode-compatible alternative

• postcard

  Similar in spirit and structure to bincode, but a bit differently flavored

• 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.