It's completely open-source, general purpose software that is essentially static (lower chance of drama or ideological/management concerns ala golang).
It would be like avoiding C because it was developed by ATT.
It would be like avoiding C because it was developed by ATT.
If a good non-Facebook implementation of ZSTD shows up, I might strongly consider using (that implementation of) ZSTD.
2. The format spec is an RFC [1]. It's frozen. We're not going to pull the rug out from under you somehow (and why would we??).
3. I think we do a pretty good job accepting contributions. But again, if we aren't, you can always fork it.
All in all, we've worked pretty hard to make zstd universal--portable, stable, flexible, robust, etc. I guess I don't really have a point... I guess I hope you reconsider your rejection of zstd? It's pretty cool.
I'm also concerned with the term "port". I don't know exactly what you put in the term, but to me, it sounds like someone basically translated the C code directly to other languages. What I would be looking for is more like a "clean re-implementation" by an independent group of people who properly understand all the algorithms which are used and where all the code is written from scratch without the Facebook code as a "crutch". This would ensure that whatever Facebook does, there will be a group of people that is capable of fixing tricky bugs in the algorithms or implementing further optimizations. Basically, I would want the alternative implementation to be as unrelated to Facebook's libzstd as Clang is to GCC.
All of that said though, from a purely technical perspective, zstd seems like a truly great piece of engineering. Kudos. Though I will never understand what drives great developers to dedicate their life to producing value for Facebook.