 Thank you all very much for the opportunity to talk about partnerships. I'm extremely just humbled and really happy to be able to be a part of this team, new member of the team, but have been thinking about these things for a long time. So today we're going to talk about partnerships and many people will probably appreciate that one of the strengths of Protocol Labs is its ability to bring in community for all these aspects of development. So this is really about community development, but thinking about it in a couple of different dimensions. So first a little bit of my background to give you some context of where I'm coming from. Based out of Atlanta, Georgia, here you got the nice Atlanta, Georgia skyline there. You can get, feel like you're there, you can smell the fried chicken almost. But no, but to give you a little bit of context and how I want to be able to help the project, started out with some full-stack development at IBM doing a lot of Java, database, front-end work, sort of traditional consulting stuff. But then I was able to join the Hadoop ecosystem early on and I actually worked at a company that had a big problem around processing large data sets and pre-cloud, pre-big data, this was a very expensive proposition. You'd have to spend millions of dollars to Oracle or to Teradata, one of these organizations and it was very difficult to scale to large data sets. Google was doing this very well and they wrote a paper about how they were doing it. Yahoo implemented that paper and that implementation became Apache Hadoop effectively. And throughout its lifecycle and being able to work in that space, I was able to work with large organizations that had hundreds of nodes trying to implement Hadoop and see really the reasons why they were using it. Very often it was Apache High running SQL on top of Hadoop for very standard SQL workloads. They wanted to be able to scale to very large sizes. But it was also a great opportunity to see how the open source community worked. And it was a really fertile space because there was the growth of the open source community. There was the growth of the partner network and I can tell you firsthand, having been a sales engineer in this space, that the partners were extremely important to our success of the overall Hadoop ecosystem as it grew. And then more recently I was able to work in public cloud and see how and why people were making this big shift into the cloud and how that changed the data structures that they were using and how that changed the way they thought about processing and all these new tools that they had available. So I'll try to kind of color the conversation around some of those dimensions. And then lastly, I was also very much involved in crypto for since about 2013, just purchasing and then mining for a time. But also I was able to work with some of the decentralized finance organizations more recently and get a good appreciation about how all that works. And that was really what led me to Protocol Labs because Protocol Labs brand is extremely strong in the crypto space. It's a foundational organization. And so I was very fortunate to be able to get connected to you guys. So a little bit about me. We'll come back to this more in detail. Love being outdoors. I hate having to drink stop drinking coffee at the end of the day. That's probably the worst part of my day because I do need to eventually get some sleep, although now that I'm on a different time zone, maybe I'll just keep cranking the coffee. So partnership goals for back will how back we out. Why do we want to have this partnership? So effectively we do want this system that's going to work elegantly out of the box. Our engineering teams and product management perspective, we're going to work on that. But we want primitives that are really going to empower other organizations. And we'll give you guys some example of what those primitives are going to look like. We want it to be a robust ecosystem. Protocol Labs will have a strong place in it, but we want to give agency to these other partners that feel like they have ownership and they can contribute. And there's various mechanisms and incentives that we'll go through in just a second. So let's put some KPIs to this. And let's say we do need some referenceable partners that when we launched in October are going to stand up and say, we believe in the vision of back or yowl. We are actively contributing and testing to this. And we want to be a part of this world. So we're setting a target for ourselves, five referenceable partners by October. And the goal is to blow that out of the water. But that's where we're going to start from. So let's go over a little bit of the landscape of partners because this will color a lot of the rest of the conversation here. The first type would be, let's say contributors or users, folks who are just essentially consuming most of the product. They use it as an alternative to whatever they were using today. Maybe they're no longer using S3 and Databricks hosted cloud service. Now they're using back or yowl as an example. And we'll go through some examples of what different types of industries that might include. The second would be extenders, people who are going to actively contribute back into the product and people that are going to roll up their sleeves and they're going to submit PRs to back or yowl as an example. These are people that'll probably have some existing component tree and framework that they want to produce integrations into their existing frameworks with back or yowl. And David, stop me if I miss anything on the characterization of these guys. The last one is very interesting. And I think this is especially something that Filecoin has done really well today is embedders. People who are going to say, to the external world, just use our product as you normally do. Behind the scenes, you'll be benefiting from back or yowl on your processing. It'll be the benefits of openness, transparency, all the things that we love about what we're building for back or yowl. But those folks will be the UI. And that's really an especially interesting area because the user experience will be the same user experience as it was before. And there's a lot of nice outcomes we can have with that group of partners. All are welcome and really all are critical for the project to be successful. We don't have this network of different types of partners. We're probably making some design decisions wrong on the way in. So here's an example. Once we have these referenceable partners, October 1st, there's going to be press launches. We're going to have awareness that's going to drive what's going on within back or yowl. And these are some of the things that they're going to say. This has really transformed the way that people are using the data now. Previously, the data was siloed. It was private. Now it's open. It's public. It's forkable. These are some of the types of things that we're really proud of, that Bahia was bringing to our projects. And also in terms of size and scope, because we don't want to just, this to be sort of toy projects, as was mentioned earlier, we're going to really push this. And we're going to have failures along the way. And we're going to push it as far as we can to have some meaningful projects because we do want to see where the bugs are going to surface. And then lastly, from an operations perspective, our SRE team is going to work on other things because this is an automated managed decentralized system that does not require full staff to maintain. So what does this profile look like of a good partner? Because not all partners are created equal. Some might be better in the future. Some might have different interests. But let's talk about the ones that are going to be good first round candidates. I have a couple ideas, but I'm very open to hear your guys' perspective on this as well. So the first one is someone that is at least philosophically aligned with the mission of back or yowl and protocol labs, championing open source. There are some organizations that are true champions because it's aligned with their philosophy and their business model. There are some that are very closed, some in the financial services industry. So they may not be that version of a good partner. Small and nimble, they can move fast. They can try new things. They have the staff to try new things. They have the ability to try new things. Some larger organizations don't have that flexibility. Maybe they're already using IPFS. The number of partners that are already leveraging Filecoin and IPFS, the ecosystem is very rich. They might be good candidates to start with. Could benefit from a public partnership with back or yowl. There are many organizations out there that have, coming from an enterprise perspective, they might have the perception of being older or less tech friendly or whatever reason. And there's very significant intentions within the organizations to say, we want to be tech forward. We want to be progressive. We want to be in the cutting edge. And this type of partnership could be good proof for those organizations that they're wanting to get at the edge of this sort of decentralized technology. Valuing open and collaborative data sets and data analytics, this is one we'll give an example here in a minute of an organization like OpenAI. OpenAI has the word open in the name of their organization. However, some components, yes, exactly. Some components of the organization are closed or proprietary for various reasons in their business model. So this gives them an opportunity to really kind of live what the meaning or the mission of their organization could be. What we did put together a couple examples, just to kind of share on the similar way of thinking, just some ideas of how we might slice this into different landscape. And we'll go through some more detailed examples here. We've got obviously some partners in the room, which we very much appreciate all of your guys' contribution. We've got the user group, the extender group, the betters. I'll go through each of these in a little bit more detail, just talk about why they might be beneficial to the mission of back or yowl. And then also maybe one sort of side comment here is maybe systems integrators. Because in the traditional enterprise world, you have these consulting organizations, maybe like Winder as an example, where they are very effective at doing the heavy lifting that these customers cannot do. And they have a great business that they run, and how do we incentivize these systems integrators to build profitable businesses, helping people run their workloads on back or yowl. So talking about users. So this is an example where their mission is to benefit humanity through open AI research. And they came up with some incredible things recently, tech-generative stuff. But a lot of that has been maintained privately. And even when the actual models are released, the data sets are not always made as available as folks might like. So if they were able to do more of their data engineering and more of their processing in a public manner, would that help them for their own mission? And it would give us at least some interesting data sets to hopefully very paralyzable workloads around sentiment analysis and those sorts of things. There's an organization named Audius, which they're sort of like an open-source version of Spotify, IPFS-centric today in terms of how they store their data, open-source friendly. There's some workloads they have which is running a content node, which is doing very, I would say, straightforward processing of audio files. Is that an embarrassingly parallelizable job? Might be. Could be a fun first workload to think about. And then obviously there might be adjustments to the technology integration that would need to happen. So we have to think about that along the way. Chain analysis is also, in some ways, a public goods organization. They do a lot of the investigations that happen in crypto criminal investigations. There's heavy amounts of blockchain data to be analyzed to see where the transactions move. And so if you ever hear someone say, oh, we caught the people that were involved in a crime around crypto, very often chain analysis is the one that's doing it for the federal agency. And if you look at their data, there are heavy amounts of their processing. And if they could make that information more public, does that further their mission to help investigate the crime? There's also some really interesting things thinking about social goods. A lot of people talked about social media and the state of social media today and making it more friendly for society. And so there's a couple of projects all they have is the lens protocol. There's a startup named DeSo. And their focus is around rebuilding these social media platforms so that the user owns the data. Those platforms themselves also need tremendous amounts of analysis in order to be effective. For example, an algorithm needs to be run to recommend content to you, just like Twitter does today. So if those systems are going to do processing on these public data sets, why not do that processing on Baccalaureate as an example? All right. So those are the users. Let's talk a little bit about some examples of extenders or people that we could use some extension from. You guys covered very well earlier in the last session how Jupyter and Python notebooks are sort of the lingua franca for a lot of data science work that goes on today. So if we think about the existing Jupyter community, how difficult would it be for us to provide extensions so that I could have my existing work that I've written in an IPython notebook and have a very easy interface to just deploy it directly the data sets or the workflows into Baccalaureate. Databricks, especially in the enterprise component here, Databricks has the most contributors to Apache Spark. They're sort of an open core business model. They do provide proprietary extensions in their own cloud offering there. But the nice thing about an organization like Databricks is they have a very large footprint among the data science community, at least in particular the enterprise data science community. And so are there components where within the Databricks ecosystem the Apache Spark jobs could be running on Baccalaureate? Lots of work to do there that might be sort of a future operation there. But this would be an example. And then Dask, you guys highlighted very well how Dask is a very popular Python-centric scaling solution. What would it take to just take Dask, drop it into Baccalaureate, allow it to run in an extended fashion? These are some fun things that would be interesting to get that team and that community involved to get their perspective on the architecture as it evolves. And then in terms of embarrassingly scalable projects, Scikit Image is an interesting one, very popular data science community, particularly for image processing. And if you think about things like Landsat and other simplistic jobs, maybe they would be a good place to start thinking about how we could integrate with those guys. And the last here are embedders, people that we want to wrap Baccalaureate under the covers so that their users don't necessarily need to know Baccalaureate is running it, but they get the benefits of the openness and the transparency. Filebase is an interesting one that is working within IPFS today. I believe Filebase had just recently extended some decentralized compute to a platform named Akash Networks, because the S3 API itself does require some additional processing for requests to translate that into direct reads. Now, Baccalaureate seems like it could be a very interesting alternative to Akash in that case. Simplistic, decentralized, the data is already native to IPFS. But this also actually in itself would be an enabler for the broader ecosystem, because many data scientists are comfortable working with the S3 API. So there's multiple points of benefit with an organization like that. And then also Fleek, Protocol Labs has done very well to help partner with and support Fleek as an organization. In particular, many web developers are coming from this Netlify, Vercel, GitHub world of deployment. Fleek has done a very good job of being the Web3 version there. So what could we do from back in YAL to give them the nice decentralized back in infrastructure? And actually, my slides are a bit strong when I say seemingly dead internet computer ecosystem. In case anybody here is from DFINITY, I do not have enough information to make that claim. But anyways, let's just say that there's an opportunity for alternatives for other compute alternatives. So systems integrators. So we talked a little bit about how systems integrators themselves have a business to run. Many of these organizations we want for users may not have the sophistication to deploy it themselves. And so when would be good to partner with an assign? If we're going after an organization that already has a consultancy that they use for these net new data science projects, that's a very easy way to partner with the assign because they are the data science wing for the organization. They have a trusted relationship with this user group that we're going after. There's opportunities for co-marketing within these groups here, so it's always good feedback as well. And to give you a bit of a sense of the landscape, at the highest level, there's sort of these global SIs, which are the sort of traditional big consultancies for enterprise. There's also a healthy group of sort of regional SIs. And there's a group of terms that might refer to as boutique SIs, which are very more data science specific or Python specific, equally valuable in their awareness, but they would be a great point of feedback as we're deploying the system. All right, so we talked about the type of partners that we want to partner with. A brief comment here on the go-to-market structure and how we would actually engage this partner community to make it as robust as possible. And there's a few different methods that we can think about for growing partners. One would be relationships, introductions. You can't discount the fact that everyone in this room has probably at least one relationship with a partner, a potential partner, or they themselves are a potential partner. So word of mouth is a great way to start. Direct outbound marketing is very effective through conference activity, grants, all sorts of different ways that you can invest in awareness of what Bahia is doing to actually bring in partners directly. And the last is just direct outreach, just prospecting directly and saying, hey, we know that we want, for example, Jupiter to be a partner of Baccalaureate, so we'll just get in touch with them directly, try to find the right people and spend time and invest going after that. So let's say we've got our partners identified. What does a timeline look like to bring those partners online? If we group it in about a three month timeframe, there's going to be some initial vetting to make sure that the design that they have in mind is the same design that we have in mind. Everyone's aligned on how we'll frame the value of this new partnership. There may be some gaps in the current technology, so we'll have a little bit of a fit gap analysis to understand the work to be done and when they can commit resources, when we should commit resources. We'll start working on it. And within 30 plus days, there'll be some point where the core initial development is ready and we can start testing and going through and bug fixing and making sure everything's nice and sharp. There's also this ability to co-marketing. So their organization is going to benefit from alignment with back of y'all. We're going to benefit. So how do we sort of both? Is it blogs? Is it webinars? Is it videos on YouTube? All different kinds of opportunities to get awareness out there. And there's also going to be things like documentation. There's some good bread and butter things to make sure the deployment goes effectively. And then last, initiate the marketing launches. We'll have quotes lined up. We're getting ready to launch. And then T-Zero Day is the launch. And so we all have our material that goes out. Everyone's aware. And then on an ongoing basis, we continue to invest in the partnership to make sure that people are aware and we grow the partnership over time. So we talked about a number of different mechanisms here to partner. Some of them are traditional Web 2 components. Some of them are more Web 3 friendly hackathons, bounties, and grants. And then eventually you could have a much more robust partner program where they have a self-service portal. They have an incentive structure. Partners could get direct payment benefits from their partnership. This is kind of common in the enterprise space. But there's a lot of different ways we can invest in the partner program. So in terms of defining success for a partner program, if we look back, let's say we go six months from October launch, and we look back and we say, was this partnership program a success? What are the dimensions that we'll use to judge whether or not it's a success? We definitely care about how many users, how many partners come on board. We also care about what's the volume of workload that those partners are contributing. Maybe they built something that's nice and shiny, but that nice, shiny object also actually contribute to real workloads that are running on the platform. How many of those partners are willing to continue to co-market? So it's an ongoing benefit for their brand and the work they're doing on their project. And actually, how much storage is that contributing to the Filecoin network? Is it making a meaningful addition to the growth of how people are using Filecoin? And then lastly, there's a lot of good examples of, let's say, well-built-out partner programs, so we're definitely not reinventing the wheel from scratch. We can draw inspiration along the way as we grow our footprint and our sort of build-out of the Backway Out project. So that is all. Thank you guys for letting me share some ideas on the partnership programs. That's all for now. Thank you guys.