它们在很多地方都很常用，所以我要说的是你的第一个假设。我不知道您对发布时间表的期望是什么，但对于这样一个规模和成熟度的库，它们对我来说似乎很正常。见鬼，AVRO1.8.0在2016年初问世，大多数东西仍然使用AVRO1.7.7（例如spark、hadoop）。https://avro.apache.org/releases.html

协议缓冲区是一个非常成熟的框架，大约15年前在google首次引入。它当然没有死：几乎谷歌内部的每一个服务都在使用它。但经过这么多的使用，可能没有什么需要改变的这一点。事实上，他们今年发布了一个主要的版本（3.0），但是这个版本在删除特性的同时也添加了一些特性。
protobuf的相关rpc系统grpc是相对较新的，最近有了更多的活动(然而，它是基于谷歌的内部rpc系统，已经经历了大约12年的发展。）
我不太了解节俭或avro，但他们也有一段时间了。

与protobuf相比，thrift的优势在于它提供了一个完整的rpc和序列化框架。另外，thrift支持大约20多种目标语言，而且这个数字还在增长。我们将包括.net核心，并将在不远的将来生 rust 的支持。
事实上，过去几个月没有太多的节俭发行，这肯定是需要解决的问题，我们也充分意识到这一点。另一方面，代码库的整体稳定性非常好，因此可以使用github fork，并从当前主代码中自己剪切一个分支——当然，使用通常的质量度量。
avro和thrift的主要区别在于thrift是静态类型的，而avro使用更动态的方法。在大多数情况下，静态方法非常适合需要，在这种情况下，节俭可以让您受益于生成代码的更好性能。如果不是这样，avro可能更合适。
另外值得一提的是，除了节俭，protobuf和avro还有一些更多的解决方案，如capt'n'proto或bolt。

关于节俭：据我所知，它是活生生的。我们使用它进行序列化和内部api的工作，我的工作，它的工作很好。
通过twitter的finagle等项目，还增加了连接多路复用（connectionmultiplexing）和更为用户友好的客户端。
尽管我将它的使用定性为半密集型（即，我们不首先考虑性能：它应该易于使用和无bug），但到目前为止，我们还没有遇到任何问题。
所以，关于节俭，我认为它属于你的第一类
protocolbuffers是thrift的序列化部分的一个替代方案，但它不提供thrift提供的rpc工具箱。
我不知道还有哪个项目将rpc和序列化混合到这样一个简单易用且完整的单个包中。
[*]总之，一旦你开始使用它并看到了所有的好处，就很难把它归入你的第二类：）