You can’t build everything.
That may be a modest overstatement, however, it’s a truism that all software-based companies, protocols, open-source projects and individuals that are working on their own start with an idea that becomes software code which morphs into a working product or feature. That’s hard work representing talented and expensive human capital time. Now the even harder work. Attracting users, tending to users’ needs, evolving, improving and extending the product. Repeat, repeat, repeat, … That’s what builds successful businesses and widely used protocols and open-source products.
Over time “what’s next?” is a constant question that, when answered, converts to “how”. Most companies use a pretty simple decision-making framework – build, partner or buy. Most often that decision-making framework skews something like this:
- Build if it’s a product feature or natural product extension
- Partner if the capability i) complements but is not critical or ii) complements and a partner can be trusted to fulfill the need for a while or perhaps indefinitely or iii) complements and the partner brings significant benefits like customer relationships or brand value.
- Buy if the capability is very important, others have already built it and i) it would be difficult to build in a reasonable time or ii) it comes with, talent, customers and a business that are a natural fit to achieving the “what’s next?”.
Of course, each path has costs which often limits what is practical. This is a bit like mom and apple pie, most acknowledge and accept this as a reasonable framework.
However, often we see a different mindset with open-source projects. We’d posit that is due to software developers both creating and managing these efforts. As is natural, software developers build and what they build is important and protected by them. Introducing a new group to their efforts creates tension, potential conflict and certainly a period of “getting to know each other” compromise. Protocols are often fundamentally open source projects. In our view, that reality has inhibited protocols from actively participating in the buy option highlighted above. This is beginning to change but not without the predicted tension as was well highlighted by the Cardano community bickering this week following the announcement of the acquisition of Nami Wallet by Input | Output.
Make no mistake, software developers rule and are the lifeblood of crypto. Over time we hope and expect those that are building protocols will become a bit more pragmatic with the expected result of more mergers and acquisitions within these ecosystems.
