Why “Shipyard”?

“Interplanetary Shipyard” is at the minimum a temporary/stand-in name. It hits on attributes like maintenance and building that are key to our team. We’re also a team that “ships” 🙂. (It also helps make clear that we’re not the “IPFS engineering team” - see ❓FAQ - Are you “the IPFS team” or “the IPFS engineering team”?)

Is this your final branding?

No. This site in its current form was put together as a start towards communicating our team. We have first focused on substance, and we’ll get to better presentation once we complete out graduation from Protocol Labs Inc at the end of 2023.

Does this relate to the Github ipfs-shipyard org?

No. https://github.com/ipfs-shipyard was created to incubate projects by the IPFS Community but didn’t realize it’s vision of incubating a vibrant set of projects. If we stick with this name, we’ll do cleanup on this organization to avoid confusion.

What is your relationship to Protocol Labs?

The IPFS Project started within Protocol Labs and many of us were originally employed by Protocol Labs to work on IPFS as well as other projects. Come January 2024, we’ll be moving out from the employment layer of Protocol Labs (PLGO) but we’ll still be part of the Protocol Labs Network. We view this transition a positive growth step for the IPFS project as an independently governed “IPFS Protocol Foundation” also get spun up. Protocol Labs Inc has given funding to a variety of groups that depend on or contribute to IPFS. As we are major contributors to IPFS tooling and the IPFS project in general, Protocol Labs made initial commitment to support our work as part of a wider ecosystem fundraising effort.

Why are you starting your own entity vs. joining another team doing IPFS development?

We want to support the IPFS ecosystem by:

maintaining and improving software that is relied on by many parties
making our expertise more generally available to people
being supportive glue that can help people connect to each other, enable interoperability via reusable specs, etc.

We think we can accomplish the above best by being more independent of an organization that has other projects and more competing priorities.

Also, per What we do, we are transitioning to broadening out to provide more consulting and support services. We believe a separate entity better facilitates this as well.

Do you think having experienced IPFS maintainers live outside of PL Inc. is good for the project?

Yes. Over our years working with IPFS we have engaged with many teams using IPFS for various purposes. While as individuals we have endeavored to use our expertise to enable the community, doing this within a company like Protocol Labs Inc, which has many projects and its own sets of priorities, can make it hard to give projects outside of that company the attention they deserve. For example, with PL Inc. also having heavy investment in Filecoin, more of our attention has been on large data concerns for the Filecoin ecosystem. The IPFS content addressable data tent is much wider than this though, and we haven’t given as much energy to decentralized data distribution needs for apps, provided seamless interoperability with the wide array of data that is already content addressed, or progressed as far on making the browser a first-class IPFS citizen. We have more autonomy now, and we believe the community has more ability to influence our work in our new position.

Are you “the IPFS team” or “the IPFS engineering team”?

Absolutely not. While we have amassed a lot of IPFS experience and we’re happy to bring it to bear on your particular problem, we’re only one of multiple teams that do “IPFS development”. IPFS is not owned, controlled, or developed by one single company. We’re proud to be part of an ecosystem of many great teams