IPFS is fundamentally about the concept of self-certifying addressing (e.g. content addressing) and the value it provides in allowing for a more resilient web. At the moment there are a number of IPFS implementations that are out there with different focuses, but we’re just at the beginning.
Some of the existing IPFS implementations include:
Personally, while I spend most of my development energy on go-ipfs I’ve also spent countless hours advising and working with the various other IPFS implementations. Sometimes we talk about protocol design or algorithms, lessons learned from the mistakes in implementations we’ve seen, or compromises made in one system that do not have to be made in another.
Speaking of the go-ipfs elephant in the room, while frequently go-ipfs gets the most attention as the first and most widely deployed IPFS implementation it’s by no means the only one, nor should it be. In particular, go-ipfs’s strength and burden is that historically it has tried to be a lot of things to a lot of different people which is a tough burden. Should the same server software running on a fleet of IoT devices be the same as the one running on your laptop, a cloud deployment or a massive server? Similarly, there is a lot of pressure with having some feature “enabled by default” for the entire userbase and how that fits with the needs and desires of the community.
Perhaps the most common of these are the countless mutability systems that could run alongside IPNS that would expand the scope and responsibility of the go-ipfs maintainers. When these sorts of issues come up we tend to move towards pluggability via some API endpoint that allows users to integrate with an existing go-ipfs binary without building a fork or using a plugin.