Podcasts about github marketplace

Scott and Wes react to the big GitHub Universe announcements, recorded live at GitHub Universe. They dive into Copilot's new features, exploring how its advancements stack up against Cursor AI in the battle for the ultimate AI-driven developer tool. Show Notes 00:00 Welcome to Syntax! 01:12 Our Syntax Meetup. 02:54 AI is everywhere. 03:22 Sherlocking and jockeying for position. 04:49 GitHub Copilot introduces alternative LLMs. GitHub Copilot 06:31 New tools are build upon existing LLMs. 09:14 VSCode reclaiming ground from Cursor. Cursor 10:31 The new features. 10:34 Multi-file editing. 10:54 Use-cases for multi-file editing. 12:58 Multi-model selection. 13:05 Repo indexing. 13:50 Copilot instructions. 14:34 Examples of Cursor rules. 16:39 No mention of multiple-line suggestions. 18:02 Multi-file edit? 20:26 Code review. 22:36 GitHub Pull Requests plugin. 24:34 Investing in AI ‘big bets'. 26:29 Scott's mysterious YouTube unreleased feature. 27:11 3-minute YouTube shorts. Wes' TikTok. 28:29 GitHub Marketplace. 32:18 Copilot Workspace. 34:53 Copilot Workspace features yet to come. 36:25 GitHub Spark. Bolt.new. 42:44 Final thoughts on Copilot vs Cursor. 44:03 What products do you think are in trouble? 50:26 Sick Picks & Shameless Plugs. Sick Picks Scott: Waymo. Wes: Waymo. Hit us up on Socials! Syntax: X Instagram Tiktok LinkedIn Threads Wes: X Instagram Tiktok LinkedIn Threads Scott: X Instagram Tiktok LinkedIn Threads Randy: X Instagram YouTube Threads

Building your business on a platform like iOS, Wordpress, or Shopify gives you access to that platform's customers, but comes with many tradeoffs. Joe helped to create the GitHub Marketplace and built his most recent startup as a Slack bot, so he knows both sides of this experience. He joins Adam and Wulf to discuss the power asymmetry between platforms and their developers; best-of-breed vs unified suites; and how Slack seeded their early ecosystem. Plus: timezones, definitely the easiest problem in programming. @MuseAppHQ hello@museapp.com Show notes Joe Wadcan (@joewadcan) Ballotshare Business Development Abstract Fantastical Evenbot shutdown posts GitHub Boards GitHub Marketplace, Heroku Add-ons, Slack Apps Slack's 5 years as a platform post Travis CI, CircleCI New Relic, Sendgrid Zynga Twitter acquires Tweetie (2010) Sherlock app

En este episodio platicamos sobre marketplaces, integraciones y alianzas dentro de un ecosistema de software: el proceso de implementación de las aplicaciones dentro de un marketplace, qué beneficios ofrecen los programas verificados de partners, cómo funcionan las integraciones con productos saas como Algolia o Atlassian y cuál es el trabajo de los desarrolladores evangelistas o advocates. Te recomendamos: Cómo crecer un programa de relaciones con desarrolladores (Heavybit): https://www.heavybit.com/library/blog/growing-a-developer-relations-program/ Serie de vídeos de DevGuild con temáticas enfocadas a enterprise: mejores prácticas para hacer deploy, el core de las funciones de enterprise necesarias para cubrir las necesidades de estos perfiles, alta disponibilidad y soporte de calidad, reporting y analítica: https://www.heavybit.com/devguild/enterprise-ready-products/ Una lista curada de librerías, recursos y proyectos relacionados con Algolia: https://github.com/algolia/awesome-algolia Te gusta compartir tu conocimiento técnico en un blog? Bitbucket está llamando a todos los interesados a ser evangelistas y, de paso, construir marca personal. Rellenas formulario con tópico, pasas filtro de editores, escribes, te lo publican y promocionan: bitbucket.org/product/write Las integraciones, apps, y bots que usa el equipo de GoSquared: https://www.gosquared.com/blog/slack-integrations Si te interesa el mundo de las relaciones con desarrolladores, consulta: https://devrel.net Productos mencionados: GitHub Marketplace: https://github.com/marketplace Directorio de Aplicaciones de Slack: https://slack.com/intl/es-es/apps Atlassian Marketplace donde encontrarás miles de aplicaciones que te ayudarán a personalizar y ampliar tus productos de Atlassian: https://es.atlassian.com Magento Marketplace: https://marketplace.magento.com Programa de Partners de Shopify: https://www.shopify.es/partners Hubot: https://hubot.github.com

Welcome to the first edition of The Azure DevOps Podcast! Your host, Jeffrey Palermo is joined by guest, Buck Hodges, to announce the global release of Azure DevOps Services. Buck is the Director of Engineering for the Azure DevOps product group and has been at Microsoft for over 15 years.   Azure DevOps Services (previously known as Visual Studio Team Services) aims to help developers ship faster. With Azure DevOps Services comes a full set of services that you can use separately, with other non-Microsoft services, or together as a suite.   In this episode, Jeffrey and Buck dive into all the key differences that come along with the rebranding and new services. Buck also gives a rundown of the system (from how it’s organized to how to mix and match with other devops tools on the market) and many of the new, exciting features available for developers.   Episode Sponsor: Clear Measure is a software engineering firm and Microsoft Gold Partner empowering development teams to be their best. Clear Measure equips developers with the devops tools, methods, and automation necessary to focus on building their applications rather than wrestling with builds, deployments, or environments. Click clear-measure.com to see whether a devops implementation is right for you.   Topics of Discussion: [:30] About today’s topic and guest. [1:00] Buck Hodges announces the new Azure DevOps Services. [2:44] Buck’s background in DevOps and career progression at Microsoft. [10:00] Key differences with the rebranding to Azure DevOps, and its 5 main services: Pipelines, Boards, Artifacts, Repose, and Test Plans. [14:49] Can Jira (and other similar softwares) users adopt Azure DevOps? [16:48] About Microsoft’s commitment to open source and giving back by offering free use of Azure DevOps to run free builds for open source projects. [20:02] About the ease of getting started with Azure Pipelines through the GitHub Marketplace, and some of the big users with Pipelines. [20:49] A word from Azure DevOps sponsor: Clear Measure. [21:19] About the internal transformation of the Azure DevOps team and what it looks like today. [24:04] How many developers are part of Buck’s organization? [24:54] Buck gives a rundown of the system (how it’s organized, how many team projects, how many Git repositories, how many independent services, etc.) [28:58] Do they build all the services together in the same Git repository or do they split them into different build configurations? [32:45] What’s coming next for Azure DevOps? [36:34] Buck addresses some general misconceptions. [40:00] When will customers be able to get their hands on the new Azure DevOps 2019 server? [41:30] Where to learn more or get started with Azure DevOps.   Mentioned in this Episode: Azure DevOps VSTS Azure Pipelines Azure Boards Azure Artifacts Azure Repose Azure Test Plans Team Foundation Server (TFS) Jira GitHub Visual Studio Code TypeScript Dev.Azure.com   Want to Learn More? Visit AzureDevOps.Show for show notes and additional episodes   Follow Up with Our Guest: Posts by Buck Hodges on Microsoft Azure Buck Hodges’ LinkedIn

Rhys Arkins joined the show to talk about automating dependency updates using Renovate. Renovate is an open source tool to keep source code dependencies up-to-date using automated Pull Requests. We talked about who’s using it, the languages and environments that are supported, self-hosted vs SaaS and how that plays into supporting this open source, auto-merging, being a GitHub App and in the GitHub Marketplace, and building this as a business on someone else’s platform.

Rhys Arkins joined the show to talk about automating dependency updates using Renovate. Renovate is an open source tool to keep source code dependencies up-to-date using automated Pull Requests. We talked about who’s using it, the languages and environments that are supported, self-hosted vs SaaS and how that plays into supporting this open source, auto-merging, being a GitHub App and in the GitHub Marketplace, and building this as a business on someone else’s platform.

En el podcast de hoy hemos hablado sobre sistemas de control de versiones, Git, GitHub, algunos concepto básicos, sus flujos de trabajo, algunos consejos y buenas prácticas, GUIs e integraciones con editores... En fin, esperamos que os guste! Blog Entredevyops : http://www.entredevyops.es Twitter Entredevyops: https://twitter.com/EntreDevYOps Enlaces comentados: La guia del autoestopista galactico: https://es.wikipedia.org/wiki/Gu%C3%ADa_del_autoestopista_gal%C3%A1ctico_(libro) Podcast BeSuricata: https://besuricata.com/ Python PEP8: https://www.python.org/dev/peps/pep-0008/ Git: https://git-scm.com/ Comparación de Git y Mercurial: https://importantshock.wordpress.com/2008/08/07/git-vs-mercurial/ GitHub: https://github.com/ GitHub Marketplace: https://github.com/marketplace/ Gitlab: https://gitlab.com/ Bitbucket: https://bitbucket.org/ Sourced: https://sourced.tech/ Tutorial Merging vs Rebase: https://www.atlassian.com/git/tutorials/merging-vs-rebasing Gitflow: http://nvie.com/posts/a-successful-git-branching-model/ GitHub Flow: https://guides.github.com/introduction/flow/ Extensión de Gitflow para el CLI de git: https://github.com/petervanderdoes/gitflow-avh CLI oficial de GitHub: https://github.com/github/hub gitsome, CLI para trabajar con GH: https://github.com/donnemartin/gitsome git-spindle, extensión de GitHub para el CLI de git: https://github.com/seveas/git-spindle Magit: https://magit.vc/ CodeClimate: https://codeclimate.com/ Travis-ci: https://travis-ci.org/

Discuss this episode in the Muse community Follow @MuseAppHQ on Twitter Show notes 00:00:00 - Speaker 1: I think every platform kind of has this tipping point where you start to see like, hey, this feature, this product is getting a lot of traction, and people building on any platform should realize they are doing R&D for the primary platform at all times. Every feature you release, every experience you have is an opportunity for the original platform to be like, hey, that’s a great idea. 00:00:29 - Speaker 2: Hello and welcome to Meta Muse. Us is a tool for deep work on iPad and Mac. But this podcast isn’t about me use the product, it’s about the small team and the big ideas behind it. I’m Adam Wiggins here with my colleague Adam Wulf. 00:00:43 - Speaker 2: Hey, everyone. And joined today by Joe Watkin. 00:00:47 - Speaker 1: Hey folks, great to be here. 00:00:49 - Speaker 2: And Joe, you have an interesting background with creative tools including GitHub and Abstract, you’ve had your own startup doing calendar slackbots and other calendaring things, but before we talk about all that, I’m very interested in your side project ballot share. Can you tell us about that? 00:01:06 - Speaker 1: Oh yeah, yeah. Ballot share is a is a labor of love. It’s much less of a business than a fun project, and it really just centers around helping people get more information when they’re about to vote. And so, People usually want to vote for one or two things when they hit a ballot, but it’s all of the minutia stuff that people don’t really have a really good sense of what to vote for or who to vote for on really local issues, but those are the stuff that really, you know, impacts them. And so Ballot share is just a site where you can see who’s endorsed things all the way down the ballot to like your local city ballot initiatives. And you can also create your own endorsement around things that you think are important and share that with friends. So the most common use case we see is people say, oh, like I have a friend who’s really plugged into education, so maybe I could ask them who to vote for for the school board president. And so they send you their endorsement and you kind of see it in a grid where you can kind of compare all of the endorsements that you want to compare. It was built for the last election cycle and we’re hoping to revive it again for the midterms. 00:02:14 - Speaker 2: I really like that idea of a sort of using your trust network if that’s the right way to put it. Maybe we get some of this implicitly, you know, there’s people I follow usually like substack where they do political analysis and to some extent I’m sort of trusting if I’ve come to trust that their analysis is good in some cases it’s that I’m reading their analysis and better understanding the issue, but in some cases it’s that I go, OK, this person. Seems to be pro this thing and I basically trust them, so therefore, I’m gonna kind of outsource that decision a little bit, especially for, as you said, all these finer details and local things that maybe you can’t deeply research each and every item. So it feels like it’s naturally what people do anyways. So as a tool to help you kind of reach that. 00:02:59 - Speaker 1: Yeah, yeah. A lot of people end up making like Excel sheets and then sending them around. And it’s actually kind of funny, we noticed that it’s not just wanting to know who endorsed it, it’s who is against certain things. So when you see like, hey, this group is against it, you’re like, that’s surprising, why? And sometimes it takes like, hey, of the 10 ballot initiatives, 6 seem like everyone is in agreement, but then like maybe 3 are kind of like up in the air. And so you, those are the ones that you personally investigate. So it kind of just puts more time to the ones that you think are actually worth the the decision to make sure you get it right. 00:03:36 - Speaker 2: And tell us a little bit about your background. 00:03:39 - Speaker 1: Yeah, so I’ve done a lot of work in the tech space, but it’s not always specifically on the tech side. So my background is I came into tech via sales actually. So I was hired at GitHub as one of the first technical minded sales people, and GitHub was a very weird beast where there were no managers and you kind of like had to understand how to do a pull request to like even do anything in the company. So, I originally did Git Up sales, focused on the enterprise clients, but switched over to BD at GitHub, maybe my 2nd or 3rd year, as just a hugely undervalued piece of the business. 00:04:16 - Speaker 2: And I’ll briefly unpack that BD stands for business development, which I think itself is probably not a super well, in my experience, it’s not even a super well understood title slash function, so maybe you want to briefly describe what that is. 00:04:31 - Speaker 1: Yeah, absolutely. BD means so many different things. It’s kind of funny. I think a lot of startups tend to use BD as just another name for sales directly, like generating revenue and talking to customers. At GitHub, it was a little bit of a catch-all, so I was running sales partnerships where we partner with companies like Ubico and get more people using two-factor keys, but it was also partnering on the technical side. So working with companies to maybe build a plug-in, and specifically my charge was everyone who’s using the API helping them do their job better. And at the time it was mostly just like a ragtag group of maybe a couple 100 people using the GitHub API. They had a very open, very public permissionless API at the time, so people just, a lot of researchers, a lot of students, but then like a handful of companies who are trying to build a business. So my job was a little bit more. Focused on getting that group of people to be more successful, and the sales partnerships happened, they were just much less of a focus, and it was a small team, we maybe had 6 people max, so we kind of did a lot with a little. 00:05:40 - Speaker 2: And you had the same title at Abstract, if I’m not mistaken. Tell us about that experience. 00:05:44 - Speaker 1: Indeed, yeah, Abstract is a funny company. They do version control for design files, and BD at that company was much more around product partnerships and mergers and acquisitions work, M&A work. And so we didn’t do any kind of like sales partnerships. We specifically focused on anything that would help the product be a little bit better, and then kind of fielding the requests and inbound we were getting from interested parties around M&A work. And so that ended up being a lot of work when we got acquired by Adobe, but it was a pretty fun ride as well. 00:06:19 - Speaker 2: And it seems to me version control is by definition part of a tool chain, part of a stack, so those partnerships and integrations are crucial because that is the whole sort of reason for existence for the tool, and I assume there’s the technical integration, but then making those business partnerships where you’re doing something together, maybe that’s co-marketing, but maybe it’s also you’re trying to serve the same set of customers together even though you’re two different companies making two different products just from the outside it seems to me like that would be a crucial function. 00:06:49 - Speaker 1: Yeah, it’s definitely an important one. In both GitHub and the, you know, abstract case, these are part of a stack like you mentioned. People are considering entire tool chains, and so we’ve got to work nice with everyone and also try to help the group itself be better cause I think there is this constant struggle in the sass world of, you see companies who want to go single suite and company offer everything under the sun, like an Atlassian or Salesforce is another one of those. 00:07:16 - Speaker 2: Microsoft is the absolute king of this, right? You sign one contract, and you get a whole suite of mostly mediocre products, but it’s OK because they fit together and, you know, you could kind of buy one time and everything you need in the software world is kind of taken care of. 00:07:34 - Speaker 1: 100%. And then you see the opposite swing where it’s all best to breed, where it’s, hey, I really care about getting the best tool for this, even if it costs more. And we see companies swing between the two quite often. So whether it’s cost related or maybe it’s, you know, new leadership, it’s like, hey, we really care about developers, let’s break out of this like low cost tooling and now give them like stuff that they want to use. So in both cases in Abstract and GitHub we were kind of managing in the breast of breed world where we were working with partners who are, you know, all trying to serve similar and shared customers. 00:08:08 - Speaker 3: And an abstracts case, if I understand right, the design files are mostly probably opaque binary to some degree, and so they would not fit very well in a git style version control, and so that’s where the abstract steps in for that really special case of potentially very large, very binary. Difficult to diff files, is that right? 00:08:31 - Speaker 1: Oh yeah, absolutely. I love talking about this cause it’s like real deep and kind of amazing that as you exactly said the Git is more suited for plain text files and You know, there are things like LFS and Git that, you know, have pointers and allow big binary files to be version controlled, but it’s really hard. And so this is exactly what Abstract it, is that they saw Sketch was market leader, but they couldn’t solve this one piece around versioning because of these big binary blobs, and so they created an ingenious solution that actually did use Git on the back end and stored this enormous corpus of design information. And was able to kind of parse through the binary and pick up changes. So, at the time it was revolutionary, you know, there was literally nothing else that did this. And so they built a very strong business on that kind of like breakthrough in being able to take a workflow that worked with developers and apply it in the design world and give designers just like a huge amount of new workflow capability. You know, they could do branches, they could do merger requests, a lot of the same things that developers have used. 00:09:40 - Speaker 3: Yeah, that opens up so much more freedom. I’ve worked with designers running up against this exact same problem, probably, well, long time ago now, over 15 years ago, but it was, it was exactly this problem of there’s one blessed Photoshop file and if that gets messed up or there’s the classic version 1 version 2, version 2 final. Nightmare. 00:10:06 - Speaker 1: Final final, yeah, absolutely. I mean this is now obviated by all the web tools like a figma that, you know, are building versioning, just like a Google doc, you know, saving every stroke, but at the time when everything is desktop based, like, these are intractable problems, so it’s kind of interesting to see how The world moves into a different medium that solves it, but then introduces other problems, like now you’ve got multi-user collaboration real time, and that’s like, you know, a big headache, but also like a huge opportunity, so there’s always something fun to be worked on. 00:10:37 - Speaker 2: I believe that the developer workflow that is Encoded through Git and GitHub, which is a more asynchronous and the merger quest as a bundle and being able to look at diss. Obviously that whole thing is way out of reach for the vast majority of people in the world. But I do think a version of that probably can and should be part of almost every kind of creative tool, certainly for design tools, again, as you say, we do see that in the real time collab and the figmas and sketches of the world. I think you see this, one reason why Google Docs is really popular with writers is they have a really good versioning system or good versioning relative to the writing tools still. Pretty basic compared to what developers are used to, but where you can see new changes when you come to a document, you can look at a history, and critically, you can choose which changes to merge or reject, or have a comment this thread that is based on a change, right? That’s one of the biggest, I think, powerful abstractions in the mental model for something like Git, which is based ultimately on patches, which is you can talk about a diff as its own thing separate from the resulting code. And so that results in poll requests and then essentially code reviews and discussions around that. And I think probably most creative tools and fields could benefit from that, but the way those tools work for developers, it’s just way too heavyweight and complicated for most people. So, stay tuned. I can switch actually has some research tracks going on this, so I hope you’ll see some essays on the topic soon. And then I think you heard that time zones are one of the easiest and most fun things to do in programming, which is why you’ve worked on several calendar products as your own startups. Tell us a bit about that. 00:12:19 - Speaker 1: Oh yeah, my latest venture was called Eventbot, and it was a Slackbot that provided a calendar, basically behind every single Slack channel. And this is my 4th real calendar startup, and I’m just a glutton for punishment here. I think that In general, I like the calendar space because I think it’s interesting to build tools around how we use our time. Like I think if you can make that slightly optimized for people, it has a huge ripple effect. But I do think it is a brutal industry that where businesses are, you know, sitting in a large graveyard of failed to ups, so I’m not ignorant of how crazy that world is, but it was a fun project. I think we saw slack growing at a tremendous rate, you know, I’ve seen a lot of different approaches in the calendar world and me and my co-founder really saw like, hey, we could build this. tool that provides a really important niche within Slack, and, you know, maybe it can grow bigger than we think and we can, you know, put it into other areas, but we just sunset eventbot after 5 years of growth. It’s been a fun ride, but I do think that the business itself wasn’t able to sustain the amount of work required to keep it going. Like as you said, time zones are crazy. Little known fact, there are thousands of time zones, not even just the familiar ones. There are many Cities that choose not to obey daylight savings times, laws that are passed on a monthly basis that change how you have to calendar. So that part of the business is super boring and extremely frustrating for developers who have to try to keep up and make sure that they’re current. 00:13:58 - Speaker 3: I think calendaring is really interesting because there’s a built-in moat for any new business, and if you can swim across the moat and build a business, then to some extent you’re safe, but it’s so easy to just drown in the middle of the moat with all of the complexity of time zones and recurrence rules and invitations and It’s just a nightmare of Minutia that just drags you down by the heels. 00:14:33 - Speaker 2: That’s right. Well, I forgot you spent 5 years of your life working on Fantastic Cal. I did pretty successful kind of gooey calendar, so you’re very familiar with the pain there. 00:14:42 - Speaker 3: Yeah, my first startup was also a web calendar back pre-G Google calendar days, and I’ve made some pretty fantastic slash horrible decisions in learning that, just kind of walking in naively into the problem space and making choices that I instantly regret. Lots of bullet wounds and scars in that space. 00:15:06 - Speaker 1: Oh yeah, there’s lots of strange edge cases in the calendar world, you know, being able to even have a consensus of what is now, what time is today, like, these are things that when you’re talking to users across the globe that the internet affords us, have just so many edge cases that we have to deal with, but Yeah, I do agree that I think building on another person’s platform has a ton of benefits, and we used a lot of them when we were building a bot, you know, primarily distribution was huge. We were early on in this slack marketplace, and so when we were building, we were finding users coming to us, which, you know, as a business that solves a major, major problem, just getting people to care or even know you exist. And in previous startups, you know, you have sales motions, you’ve got marketing efforts, and here you kind of at least, if you can solve that piece, you can focus more of the efforts on product, on delivering unique interesting value to customers. But like you said, there’s lots of kind of catch-22s in that bargain. But in the beginning days for us, we found it to be extremely valuable. We started with a free product that was truly broken. Like, I was super surprised when people had used eventbot to begin with. We had a calendar product where you could create a start date and time for a meeting, but you couldn’t create an end date and time. We launched it without that feature because we were not even sure what we were building, and we got some really, really gracious folks who were like, oh, I wanted a calendar built for Slack. You should build this. And we use, you know, the community who was adopting a free broken product to help us improve it and actually put an end time, and then subsequently actually really improved the product, but it was a blessing to kind of get user traction, even at the early days. 00:16:54 - Speaker 2: And I was sorry to see it shutting down because I’d been a user earlier on, but I was impressed by your, I guess it was an email or Slack message. I can’t remember where I basically described, hey, you know, we’re sunsetting this product. Sorry about that. Here’s exactly what customers can expect, and I think how to gracefully. Set of product which you know guess what does happen in the technology industry and there’s lots of ways to do it that I think are not very conscientious of the needs and even feelings of those end users and customers and there’s ways to do it that are more graceful seems like seems like you manage the latter. 00:17:29 - Speaker 1: Yeah, no, I appreciate that. I think I’m probably like you all have been on the other end of that, where you get an email saying like, hey, this service is shutting down, and you’re kind of like, uh, like the world is worse off, and we at least wanted to make that pain a little bit less, so, you know, we started making all the features free, so people can kind of export data. We gave customers months and months of notice so that they kind of knew, but in the end, You know, we realize that we’re stewards of other people’s data, right? And so if we’re going to be cutting our service, then we don’t want people to feel like, hey, I made this investment and now I don’t have my information anymore. 00:18:04 - Speaker 2: And on top of everything we talked about, somehow you managed to be a teacher inside of all of this. I don’t know where you find the time. 00:18:12 - Speaker 1: Yeah, neither do I, actually, it’s kind of funny. Teaching is something I stumbled into 2012. Actually, while I was building a different calendar startup called Calico, way back in the day, I ran out of money, and I started to, you know, think about what I could teach, and I just graduated Berkeley’s grad school, so I was like, well, you know, let me go back and Try to teach something I know, which was, I just learned how to code, so I taught an intro to code course. And, you know, at the time, intro to coding and boot camps were like all the rage, so it was a pretty well received course. So I’ve now taught two courses at Berkeley for 10 years. I’ve taught an intro to code course for non-technical people. Which is really like a primer into how not to sound stupid in front of developers. 00:19:02 - Speaker 2: I think that’s the, that’s the primary reason I think people take my course, that is to say, people that want to, they work with technical people adjacent to them, maybe similar to like a sales role, for example, and they want to be able to speak the language and interact and kind of reason better about that, not necessarily get a career as a software developer themselves. 00:19:20 - Speaker 1: 100%, yeah. I think the largest percentage of people who take the course are people who want to transition into product management, and they’re working, you know, day to day with engineers and they want to understand real life expectations, like, how does this code work and what are the restraints and constraints that I have on my job. It’s a super useful course that we’ve got fine tuned to make it be very practical, which is not often the case for courses in academic institutions, but, you know, we we try pretty hard. And then the second course I teach is sales for startups, where, you know, I believe that sales is just an incredibly powerful skill, whether you are, you know, at the startup phase and a founder trying to sell people on the company, on the vision, and, you know, the funding, or you’re selling to customers and trying to get them to make a purchase, so. The two courses I teach are really intended for folks to have an ability to do something in the startup world. You’re either building something or you are selling something. But if you wanted to join a startup, I’m hoping that, you know, you take some of these courses and you feel like, hey, I can join this world of startups, I don’t need to necessarily go to a big company and try to like find a niche. So yeah, it’s been fun. I definitely enjoy it. There’s a long story of like how I feel teaching, especially these past few years where it’s been, you know, much harder, remote. I think every semester we’ve had a fire, an active shooter, smoke, virus pandemic, like, it’s been a crazy past 5 years, but in general it it gives me a lot of joy. I think something that I don’t think I can replace anymore in my life. It’s a really fun thing I get to do. 00:21:00 - Speaker 3: I think those are really interesting courses because you’re teaching kind of each side of the company about the other side of the company. You’re teaching the non-technical folk. Here’s kind of the problems and the struggles that they have, and here’s how that side of the technical people function, and then also helping teach the technical people. By the way, this is what sales looks like. This is why the other side of the company is a lot harder than just Sitting behind a desk and telling you what to do with a product sheet and timeline. 00:21:27 - Speaker 1: Yeah, I agree. I think it gives the other side a little bit more respect for these roles and what they do and what they bring to the companies. It’s also a lot of fun to teach. 00:21:36 - Speaker 3: Building that empathy within a team, I think is so important when you have an extremely small team in a startup, so that everyone knows the importance of everyone else’s role and responsibility, and you end up, I think, just so much more efficient than a brilliant engineer who doesn’t understand sales and customer needs, or someone who’s really in touch with the customer, but has no idea how long it takes to build particular features. 00:22:03 - Speaker 1: Yeah, I think it creates better entrepreneurs as well. Once you start to realize, like, hey, if I have to look at this idea through the sales lens before I start, like, is this a good idea? Does this have legs, you know, on the technical side, on the business side, channel, marketing, like all of those things are really great to think through early on. So hopefully I catch people while they’re still, you know, in school and kind of incubating things. And I’ve gotten really great letter, you know, this is off topic a bit, but I continued to teach now for a decade because I get these incredible emails where they’re like, 5 years later, someone will be like, hey, I just realized that like, I learned this thing that I’m using, like, in my job. I learned it in your class, like, awesome job, thanks for, you know, helping me out, or I’ll get people being like, I have an interview next week at this company, like, I think I know what these depth tools means, but like, can we chat about it? And I’m like, this is amazing, this is a different level of impact. So it gives you a lot of satisfaction on a long term basis. 00:22:58 - Speaker 3: Yeah, that’s really rewarding. 00:23:01 - Speaker 2: So our topic today is building on platforms, and especially building a business on a platform. And we have some interesting collective experience here in this group, Joe, you’ve been on the kind of platform provider side at GitHub, you’ve been on the platform, let’s say, consumer or developer side at Eventpot or building on the Slack platform. Obviously, Wulf, you’ve been on the various Apple platforms in different forms for a decade, more than that. So, I thought it would be a good chance to compare some war stories here and understand better what it means, what sort of trade-offs you’re making when you do build for a platform. But as always, I like to start with a definitions, I’d love to hear from you, Joe, and then maybe from you, Wulf, when you think platform, what does that mean to you? What are some that you think of as maybe good or bad examples, and what does that mean for a business? 00:23:54 - Speaker 3: When I think of platform, I think of A company with existing customers that wants to let other companies have access to those customers. And somehow takes money from both sides. And so it it ends up being most good for the platform provider. And then secondarily good for the companies that get access to those customers. 00:24:21 - Speaker 1: Yeah, I think that the customer focal point, I think it’s probably the best starting point because, you know, whether it’s a product or some sort of just customer relationship, that’s the value that they can bring to other ecosystem partners who want to see an opportunity, and I’ve talked to a lot of larger companies that are considering just creating an API itself, like that is a starting point. And part of the reason they do it is, you know, a product can only fill maybe 80 85% of any customer’s needs, but there’s always gonna be those edge case requirements that might not be in the company’s best interest to build, but you still want your customers to be happy. And so I think an ecosystem provides the ability to have happier customers while maybe ceding some part of the pie or the product portfolio to a third party. 00:25:11 - Speaker 3: Yeah, and ironically I think in seeing that to a third party, you almost Entrench yourself to your customers, because now the customers to leave your platform have to leave not only you, but also all of these other extra companies that are building on your platform. So it’s a lot more difficult for me to walk away from Google, because Google is everywhere and everything integrates with Google. Yeah. And similarly for Apple, it’s really hard to leave Apple because of the iPhone and the Mac, and the App Store, and the TV and the, you know, etc. etc. 00:25:44 - Speaker 1: Yeah, it really creates a second network effect, in addition to whatever product, you know, pull you have primarily, it adds an entirely different layer of, you know, wanting to stay, and, you know, there’s lots of times where maybe the primary product is, you know, maybe lacking, but the ecosystem is super strong, and so it keeps people engaged and helps people really feel like, oh, I can’t leave, where else can I get these very customized ecosystem tools, and it’s hard to build. Once it’s built, it’s a machine. 00:26:14 - Speaker 2: The platform play is one that, you know, investors love as a holy grail of money printing machine, you know, Microsoft in their glory days, the Windows glory days was probably one of the most prime examples of this, maybe even to your point, Wulf, where it’s not necessarily that people loved Windows, the operating system, or would have chosen that above other choices available in the market. It’s just when all the programs you need run on it, of course. You’re gonna use that, and then, of course, that’s also a nice circular thing where if you’re a developer, you, of course, want to build for where your customers are. And when I think of platforms, obviously operating systems like Windows, iOS, Mac come to mind. The web is sort of a more open, loose collection of technologies that does represent a platform. And then maybe some more recent examples that are maybe more specialized might be something like Shopify or WordPress, right? Building a WordPress plugin or building a Shopify app, there’s actually quite a lot of possibility there, especially for a small developer within that ecosystem, and you can find customers that you would not be able to find if you were building something standalone. 00:27:22 - Speaker 3: Almost makes me think there’s a Maybe a gradient between an application that has plug-ins and a platform that has apps like WordPress is an interesting example where it is a platform, but it’s also just an app that I can install on a server and kind of do my own thing with. 00:27:41 - Speaker 1: I think you are onto something where there is a spectrum of how the integration happens, you know, there’s platforms where you don’t need to even know who’s using the platform. It’s just you provide the surface area and other people can build on top, or there’s something that’s deeply integrated where it’s like, you know, in the user interface. We saw this at GitHub where we had a lot of people who used Chrome extensions that like injected UI into the screen and It was weird for us to consider, like, are they plug-in partners because they don’t really talk to us, but they are in our customers' eyes, so we have to care about that, but I do agree there is a spectrum there. 00:28:20 - Speaker 2: Well maybe that’s a good chance for some storytelling here. So yeah, GitHub, you helped build out the marketplace. What was the drive for that and what was that experience like? What did you learn on the platform creator side of the equation, I guess. 00:28:33 - Speaker 1: Yeah, so the GitHub Marketplace was a multi-year kind of dream of mine, and uh to be honest, I think it’s because working at GitHub made you really see how undervalued, underestimated developer tools were as a broader category, and this is 2010. In terms of context. So we saw that people were using developer tools like GitHub, but we knew that we were going to be a best of breed company. We were going against the like single suite approaches. And so, to really shine in a best of breed, you need a lot of breed, like you need a lot of people. You want to let a 1 1000 flowers bloom in that space. And devtools were a difficult thing to grow. And so, in general, they get a marketplace was kind of like a long term intention of how do we grow the DevTools space with the position and kind of responsibility that we have as being on the version control side, which is a very base layer for a lot of developer tools. So we were building a platform that really intended to help developer tools blossom. And take away, you know, some of the parts that they really didn’t want to do, which was sales and marketing. So, we can definitely talk a little bit more about how that happened. It took a couple of years internally to get some buy-in and then externally to build the trust, but it was a really fun project which now, you know, get up marketplace is thriving and booming, so I look back pretty fondly as like, ah, cool, we helped do that. That’s a pretty nice feeling. 00:30:07 - Speaker 3: Yeah, one thing I’m really curious about is That step from 0 people on the marketplace to 1 person on the marketplace, right? Just getting that very first use case and that very first business to buy in and get going, to start things off. What was that like and what was the process to kind of maybe find that business or make sure that you had enough there for them to integrate with? What was the minimum viable product, so to speak, of A platform. 00:30:40 - Speaker 1: Yeah, I think that’s a really good question because we started by having an API that people were already using, so people were able to get information in and out of the GitHub system. It wasn’t super well loved in terms of resources, but we had people using it, and there were businesses that were created, they were just very, very small. And so that the primary example when people think about the GetUp ecosystem is a CI tool, a continuous integration tool like Travis or Circle. And for folks who are not familiar with what CI tools do, they basically do a check on your code. So they are looking at your code to see if there’s any errors, does it pass the test that your own developers have written, and it just gives you back like a hey, pass or fail. And so those tools existed in the market and used our API, but they were basically totally separate entities. People would come to GitHub, buy GitHub subscription. Use it, and then go to these independent websites directly, you know, find them, hope, and look for a logo that said, hey, integrates with GitHub, and be like, OK, great, like, maybe I can also use this in addition to my version control software. And so, my first V1 was really to create something very lightweight. At GitHub that allowed some traction and kind of proof of value to exist, to kind of build towards this marketplace ideal. And so our V1 was really simple and it’s kind of embarrassing, but we just did a simple static page. It was like GitHub.com/sh apps or app directory. There was a bunch of users who had apps, so we had to change the URL, but the original static web page was just a single page where we just hot linked out to every single tool that we knew that was reputable enough to be recommended, but also integrated with GitHub directly. And it was an important first step that I kind of didn’t really appreciate at the time. It was just mostly like, hey, how do I make progress? Well, this seems like a good way. But it accomplished two big things. One, it gave direct traffic to these providers. So, you know, Travis CI, Circle CI are common ones. They were starting to get a lot of traffic. You know, GitHub at the time was a top 10 website in the world by traffic. And so us redirecting even. In a small sliver was able to give them, it’s a huge boost for devs who, you know, are looking for CI tools. They’re like, well, why don’t I start here at this GitHub app page and then go out. So we were getting a lot of goodwill by those companies who are getting free traffic and likely, you know, a lot more revenue from it. But it also served the purpose internally, where we had, you know, lots of management to convinced that it’s worth building a bigger marketplace, because now we can see how many people click through. We actually requested from the folks who are on that static page, like, hey, could you send us a report at the end of the year on like, how many people bought subscriptions through you? We’d love to know cause we’re gonna put in a referral link, so we wanna know how much it converts. So it was twofold. It was really helpful from the inside to kind of validate like, will people click, like, and if so, which partners will they click on, like which ones do they not care about? And on the external side, we gave people almost a full year where, you know, we just drove traffic. It was also just a really good time. Once you start driving traffic to people, then they start wanting to talk to you more. They’re like, hey, can we be higher up on this marketplace, and what are the rules and what can we do to help? Do you guys talk to your sales teams about us? I guess that’s a third benefit I kind of failed to mention is our sales teams loved it. They used it in like every sales pitch. They pull up the page and they’d say, hey, listen, you’re not just buying a single best of breed tool, you’re buying into a network of tools. And showing them this kind of wide world that existed. So, it was a good use case for a lot of people and really low lift. We’re talking just a flat HTML page with some links and icons, so it was great. 00:34:36 - Speaker 2: Yeah, that points to one of the first big benefits that comes to mind for me with building on a platform, and that’s distribution. And that could come in the form of direct traffic driving, but it could also come in the form of, I don’t know, you’re making a plugin or an extension to a thing the customer already knows and you benefit from the fact that they’re already a user or a customer of X where X is GitHub, and so you say, OK, so this works with a product I’m already using, and so it’s easier for me to imagine how that plugin or app or integration fits into my life. So, just by itself, you’re already benefiting from that, but then there’s the additional huge distribution benefit of having some kind of a marketplace or an app store, even this static site you mentioned, where you have really direct distribution channel right out of the box. 00:35:26 - Speaker 3: That story is really a perfect summary of how I think about two-sided markets and platforms like that, where GitHub was already extremely valuable to the developer, just as source code repository. But then adding in those extra partners, it becomes exponentially more valuable for those developers and exponentially more valuable for those partners, where it’s really a multiplying effect. When you bring in those extra companies, those third parties, make it so much more valuable than just the product alone, and it’s even much more valuable than me going to GitHub and then me going to Travis, but having that integration makes both of those. More than twice as valuable when they actually integrate and talk to each other. 00:36:15 - Speaker 1: Yeah, it was definitely good timing for the developers themselves. We had a lot of devs come to us, run these big, you know, annual conferences that could have at the time. They’d say, hey, like, I want to build this business, but like, nobody in our team wants to do sales. We’re like, OK, we totally understand that. Like, we as a company of dev tools, like, as developers, we understand not Wanting to take care of this business, let us help you with that piece, and at least make that a lot easier. And then you focus on building the best developer tool and trying out something. So, I do think that you’re right. It helps multiply efforts. And then if you have an app store, it attracts more people to want to start a developer tool or at the time, you know, a plug-in. And so it creates a bit of a flywheel in terms of creating more people in the ecosystem, which attracts more people to the ecosystem and really. Making the whole better bit stronger. 00:37:09 - Speaker 2: And maybe if I can offer a similar origin story from my own experience, maybe just a few years before you were working on the GitHub Marketplace there, Joe, I was working on the Hiroku add-on system. Oh yeah. And this is basically a way that you can, yeah, you have the same storefront, you can provision services of different kinds, databases, logging and things people need for their apps through this little store. And the way we bootstrapped that was, we went out and did well business development. One of my colleagues did a great job identifying some three really good examples of this would be an incredibly useful service, and it shows the kind of shape of Of the overall add-on system we would picture, and one of those was New Relic, which is analytics, one of them was SendGrid, which helps you send emails, both things that a lot of apps need, and the third one’s actually escaping me right now, but it was like a good sampling. And we worked with them directly to do the integration. We didn’t have any kind of provider API we just kind of sat down with our developers and figured out how to plug it together, and from that, that served two purposes. One, we could see some patterns on what we should actually do in terms of making the API for more broad use, but second, now getting new people on board, we can point to the. Businesses that were already reasonably successful in their own right, people could picture other developers or businesses could picture, oh yeah, I can see why Sendrid and Hiroku or a new relic and Hiroku working together. That’s exactly as you said, Wulf, greater than the sum of its parts saying I want in on that, and then that’s the bootstrapping point and you go forward from there. 00:38:43 - Speaker 1: Oh yeah, Kauna’s add-ons were a big inspiration for what we were doing at GetUp, to be honest. I think we saw the ability for customers to like point click, and then add things to their bill that, you know, wasn’t previously there, but went through a different, you know, procurement model and added on to an existing subscription, like that was just a beautiful. Way to integrate that on a sales side but also on a technical ability just to know like, hey, these things are all gonna work together. I don’t have to worry about compatibility and stitching versions together. It was really nice. 00:39:19 - Speaker 2: Yeah, it’s great to hear. Now that probably does also point to one of the risks or downsides of being on a platform, which is potentially the platform owner owning the customer relationship, which there’s a lot of value in that, whether that’s the billing or just the sense of the trust kind of goes there, you know, maybe. Amazon for its third party sellers is a good example. When you buy something from Amazon, you’re really trusting Amazon and you’re paying Amazon and you think of them as the provider even though maybe the vast majority of stuff on Amazon’s site actually comes from third party sellers. And so overall, you have a power dynamic between the people making the platform and the individual developers that is pretty asymmetric, and there’s certainly a lot of historical examples in the tech industry, I think of Facebook and Zynga as being a pretty famous one, but also Twitter, they at one point early on were more of a platform thing. They had an API and building Twitter bots and Twitter clients and things, and at some point they decided, you know, we actually don’t really want to be a platform, we want more control. We want to be a product, we want more control over the end user experience. They bought Tweety, which is one of the bigger clients, and they basically overnight essentially made their API not very valuable, and they’re explicitly telling their business partners to go take a hike. 00:40:37 - Speaker 3: The risk of being on someone else’s platform should not be downplayed, because Whoever is running the platform has a favorite, and their favorite is very likely their own customers. And so if their customers in that business model need to take a left turn or right turn, they’re gonna do that. They’re not gonna consult you. And so it’s very easy to be building on a platform and then suddenly realize that you’ve been left in the dust, either explicitly cut out like as in the case of Twitter. Or there’s uncountable numbers of Apple Sherlocking other apps and kind of saying thank you, that’s a great idea. I will build that instead and taking all of the market share for themselves for particularly successful apps. 00:41:27 - Speaker 2: And I think it is tough for platform creators because they do have to balance things that can and should be platform features that are built in first class things because they’re useful to everyone and so forth versus things that are in that extended. Ecosystem. The term Sherlock, of course, is interesting because that was basically a search app, I think, for Mac, and at one point, Apple comes along with Spotlight and makes it so that that app is now sort of a feature of the platform. And I think sometimes that sort of thing can be overrated, that, you know, the built-in feature in a platform can be kind of like a really simple stripped down version. And then you can, an app that does a similar thing, but a much more sophisticated version or targets a different audience or something like that, there’s still possibility there. But you’re basically always at risk for that. Yeah. Joe working on GitHub, did you have any places where you had to balance that, like, gosh, this should really be kind of a feature of the platform, but we actually we have this pretty important developer and we don’t wanna screw them over. 00:42:31 - Speaker 1: Oh yeah, yeah, I think every platform. Kind of has this tipping point where you start to see like, hey, this feature, this product is getting a lot of traction, and people building on any platform should realize they are doing R&D for the primary platform at all times. Every feature you release, every experience you have is an opportunity for the original platform to be like, hey, that’s a great idea. And yeah, GitHub we had this exact same thing where We were just a year into creating our app directories, so we got a lot of internal buy-in around, hey, this ecosystem is important, but we noticed that issues, GitHub issues specifically was a feature that was left behind in a lot of the development we did on the platform, so it hadn’t gotten a lot of upgrades it needed, and specifically, there is a way to view issues in a combo board that people really wanted and were flocking to these external providers. I mentioned some of the providers were plug-ins. These plug-ins were Chrome extensions that injected information onto the screens, and we had lots of big customers say like, hey, we love this feature, but we can’t have people injecting into our employees' browsers. Like, that is dangerous, and we don’t want to continue doing it. So we want you to build it. And so that was one of those moments where GitHub realized like, hey, we’re gonna have to build something in this space, it’s hugely important to all of our customers. And I’d like to say that we did a great job, but I’d truthfully say we did an OK job of letting our ecosystem partners know that this was coming. Basically, when it was halfway realized on an engineering front, we reached out to that team and said, listen, I’m just telling you now, we’re going down this path, we’re gonna build something. And of course it wasn’t the months of advance notice that they would like, but it was at least some heads up. And I think this is part of what The responsibility is for platforms that are trying to really encourage growth, is that you kind of have to take communications and transparency as a really important value. So for us that meant just telling them this existed, this is the feature set, because it allows ecosystem partners. To adjust. It doesn’t have to be the death of their business, and in in our case it wasn’t. The ecosystem partner that we told was like, OK, thanks, we’re gonna create communications just for this new release, so that we can talk to our customers and say, listen, this is a good thing, we’re happy. And it allows them to adjust their roadmap. Now if they’re gonna make more investments for the next couple of months or years, they can now say, hey, this base product might be taken, but what advanced features can we do? And that’s exactly what this provider did. They created a ton of new premium features that we knew we were never going to build. Like that was a full-on project management suite, and we couldn’t, I didn’t want to build that. We just needed to have some of the visualization stuff taken care of. So they created a fully thriving business, they ended up getting acquired down the road, but that heads up has a lot of value in terms of just goodwill, honesty, and then just better investment and resource allocation. 00:45:43 - Speaker 3: Makes me think that, especially early on in a platform’s lifetime. A lot of the Businesses and players on that platform are not necessarily building businesses, they’re building features. And so then it’s easy for them to get kind of obliterated by the platform maturing and implementing those features, as opposed to what you just described where it was someone who had a business. They were project management business, and they happened to also implement this feature. And so when GitHub kind of pulled the rug out and stole that feature from them, Well, they still had a viable business and so that, yes, of course, things changed. But they were able to continue adding value on top of the platform. 00:46:28 - Speaker 1: Yeah, and I’d say for us, those early days when we were trying to create this ecosystem and eventually the marketplace, a lot of it is rides on goodwill and people seeing that you can create a business, that it won’t just be, you know, outsourced R&D that just gets gobbled up. So having some kind of shining lights and Good examples where like, hey, we did something that was in our ecosystem, but also that provider is saying good things about us, like, that’s a really strong signal that makes people feel like, oh, I can spend the time and build something on this. So in the early days, transparency is so critical, and I will say the other thing we did was, we were really human about it, so we started doing these in-person meetups with our ecosystems. So we got to know them personally, they got to know each other, so that kind of glue was really helpful when we were doing something like this, cause they knew us as people, not just like the other end of an email address, so I think Also, you know, as many other things comes down to like human relations, and I think this is just a piece of that. I’ve been on the other side, you know, on the slack side, and maybe it hasn’t gone as well, but there’s definitely moments where that human side is just critical. 00:47:41 - Speaker 2: Well, maybe that’s a good transition to talking about event pot and your experience building on the Slack platform. So Slack’s a good example of something that was an incredibly successful product. It had reached kind of market saturation, even certainly among certain kinds of power user and technically oriented Silicon Valley teams, and they came along with not just an API but a marketplace and a way to essentially build a pretty full featured app on that platform. Did you start with the idea for the business and then think maybe we should build it on this platform, or was it actually the other way around is seeing this new platform rising you saw as a business opportunity and then thought about what to build on it? 00:48:21 - Speaker 1: For us, it was definitely more seeing the platform exist and do very well, and then just having the context of having so many calendar startups, you know, behind me realize like, hey, I can put these two things together and maybe create something unique here. There’s always these moments where I would go home for like Christmas. I’m from the East Coast, I’m originally from New York, but I’d go home for Christmas and be like, oh man, I’m like in slack all day, and like, you know, people my age working at other companies would be like, what’s slack? I’d be like, wow, the difference between me in the valley and like people in slack overload between like 10 different slack workspaces and then coming to the east coast and having to explain what it is. I was like, wow, there’s still a lot of opportunity left here. So I think that was a good prompt for like, hm, if we’re gonna build a business, this might be a good place to go. And so that we started down that path and realized this was an area that was overlooked and highly, highly valuable. At the time there was like some basic integrations for calendars that Slack themselves had built. This was an interesting tactic as well. They were seeding their own ecosystem by creating their own plug-ins, so they created a plug-in for Outlook and a really bad plug-in for Google Calendar, among many other tools that they built for, but they did these things as a way to Cover the kind of product needs that their customers would have until the third party themselves built that tool, and I think that was a really interesting thing to see. I also had a lot of, to be honest, a lot of GitHub employees went to Slack, and so they would be like, hey, like this is going really well, this business is is booming, and so that’s not gonna say that that didn’t affect a little bit of my, you know, choice of where to build. 00:50:05 - Speaker 2: On the point of a platform creator making their own apps. Obviously Apple does that, Microsoft does that, game consoles do that, but we did a bit of that at Eroku, and it was partially the seating, as you said, where we would see there was just something needed, that was pretty foundational, and in some cases we would go find entrepreneurs we who that we thought would be qualified and essentially talk them into to start. maybe the first Redd add on was kind of done that way, but in many cases we would build ourselves, but trying to use the discipline of we don’t get any privileged access, we’re working through the same API as everyone else, that team is a The business unit would be a strong way to put it, but we kind of try to envision them as a little in-house company that is on the platform and then learn from that. What are the frustrations, what are the pain points, what are the ways that this is not a good experience for the developer. So, in doing so, we serve both those purposes, kind of plugging a hole, but also dog fooding our own platform. 00:51:05 - Speaker 1: Yeah, absolutely. I know that on the slack team they did this where they built the calendar integrations and then regularly sent usage reports to those companies being like, here’s how many people are using it, like, is this worth it now? Is it worth it now? And I think, you know, eventually it works, but it takes a while sometimes. 00:51:23 - Speaker 2: Now you spoke about trying to be a good communicator and be human and all that sort of thing and when you were on the platform creator side of the equation, being on the other side of that, how do you think Slack did or what was your experience like? 00:51:35 - Speaker 1: Yeah, I think Slack had a lot of great things that they did, and overall were very net positive as an ecosystem and platform creator. They were able to allow a lot of businesses to thrive, but I mean like all companies, it’s not all great and they had some missteps. I think for us specifically we experienced, you know, this exact kind of like encroachment into our space that every kind of platform creator. Fears. So we were building a lot of features, especially around the Google Calendar product, and kind of unbeknownst to us, Slack had been working on their own second Google calendar integration. I think I remember this very vividly cause we actually were invited to speak at their conference. It was called Slack Connect, and I did my panel and it was great, and then later that day they unveiled this calendar integration that Really, really was a bit of a gut punch to us. I think these are times where, you know, you wish communication were a little bit more open and trust was built up, you know, we know that we are one of many. At the time there was probably 4 or 500 apps in their Slack directory. So we knew that we weren’t, you know, the only folks there, but These are the moments where having a little bit of goodwill goes a long way, cause we saw, you know, our installs dropped huge percentage, and customers were reconsidering cause they were like, well, maybe I don’t need eventbot. So it kind of put us on our heels, and it took us a very long time to readjust our roadmap to figure it out. I mean, we’re a team of two at the time, so you can imagine like, If you are changing any investment in roadmap, like, you can only do a couple of features at a time. It’s really hard to do, to be resourced and strap right there. So, it was tough. I do think Slack has gotten a lot better. Their ecosystem team has done a really great job now of literally creating a combo board of features they are building, and they’re pretty public about this, so they are at least giving folks a heads up into spaces they will go. They also do this for infrastructure, you know, hey, to be on the slack platform, you’re gonna have to have this technical back end, and so they’ve given people a lot of notice that these things are gonna change. We had an incredible experience with people finding us organically, and then being able to take that interest and create products around it. But I think it’s always been a challenge to see further than a couple of months or 6 months down in the road map, because you don’t know what Slack is gonna do. They’re under deep competition with Microsoft Teams, and so you kind of are hoping that like, hey, I hope my niche isn’t too interesting to them, that they want to take it over, but interesting enough that they think that we’re valuable and want to like help us out on the sales side. There’s a fine line there, but Overall, I think that they did a pretty good job of allowing entire businesses to form, and many of them, you know, have now been acquired and have spun out to very large things. I was just talking to the folks who ran Disco, which was acquired by CultureAmp. And then Troops, which I think was maybe the largest Salesforce add-on, got acquired by Salesforce directly. And so there have been definitely some strong successes that came out of that, and Slack was smart about it. They even had a fund, I think that’s probably one of the more unique things I saw. They created a venture fund attached to their ecosystem, so they would definitely try to be financially aligned with their ecosystem as much as they could. 00:55:04 - Speaker 3: I’m curious about your experience. Building on Slack, but also building a Google calendar. It almost strikes me as building on two platforms at once, to some degree. One very stable, it’s been around a long time. Google Calendar is probably not gonna like shift underneath you. But do you see that being very common? Maybe in the GitHub world as well, or in other interactions you had with creators on Slack where they had feet in multiple platforms, and if any one of them changed. Then they were in a tough spot. Does that increase the risk, or do you think in that case, well, Google Calendar is stable enough, it really didn’t increase your risk. The momentum of slack and the dynamic nature of that platform is really where all the risk was anyway. 00:55:49 - Speaker 1: Oh no, I think you’re right, it dramatically increases the risk. You’re, you know, toxing your ability to keep up and even just to do maintenance and keep it running, like you have lots of risk of it blowing up from either side of the connection. I will say that it’s actually pretty common in a lot of the bigger ecosystems to have these kind of two-sided integrations. They’re essentially just like really beefed up zappier plug-ins, like this could be, you know, something you could automate, but like, here’s a tool that does it. We actually took out a lot of that risk, because what we did is we integrated with Slack directly via their API. But then when we integrated with every other calendar, we used the dot ICS kind of Cal format, which is an international standard that almost every calendar can integrate with. So we kind of intentionally didn’t go the even deeper route with Google Calendar, knowing that it was going to be much more difficult to like maintain and increase, and customers every year would give us these like top requests, and that was probably one of their biggest requests is I want it auto populating. Instead of like, hey, you just have to connect this ICS calendar and it’ll populate in under an hour. So we kind of took the customer dissatisfaction to give ourselves a little bit more breathing room. But yeah, it’s a really good point that those two sided integrations can be a gold mine if you find a really good niche and build it out, but it’s a risk that, you know, either side ends up saying that’s a great idea, we’re gonna do it. 00:57:20 - Speaker 2: And coming back to what I mentioned in the beginning, which is sort of the technical side of a platform to build on, and the business side, called the distribution aspect or the partnership aspect. I’m curious for the case of building eventpot. How much was Slack’s API and the technical infrastructure and the fact that maybe you don’t need to worry about user identity or you have a bunch of existing kind of UI concepts like channels, for example, that your users already know and you can skip forward to some unique value that you’re providing versus, you know, making basic login pages or onboarding flows, how much was the value in that versus Either one, you’re in their marketplace and people just search there and find you, or even just that they Google Slack group calendar and they find you. 00:58:08 - Speaker 1: Oh yeah, we ran a lot of those ads too, very successfully in the beginning, but the ability to not have to deal with common overhead for us was a really big boon to creating our company. Knowing that we didn’t have to worry about maintaining user databases and Keeping track of like every workspace and all the details that essentially Slack takes care of because that’s their products, bread and butter. We could essentially use that and bootstrap off of that. So it saved us countless hours of time, and also I think for a lot of our customers, some of them are, you know, very big businesses, they would have really deep requirements if we even wanted to build that for ourselves. So, knowing that Slack like has the resources and has the kind of edge cases filled out, great, it allows us to focus on much more. Unique value adds on top. And I think also channels as a concept was new to people. I mean, they understood threads of email, and then when you move to a channel-based kind of topic discussion forum, they didn’t know how to react and so it allows you to take that space where it’s not defined on what it should work like, and then add to what it could work like. As an example, a lot of people had a Happy hour type slack channel that they would just use for happy hours. And so we would say, oh, we can create a calendar behind that, and every channel gets its own calendar, so everyone can create their own events that live inside of that channel. And so we started pushing the boundaries of what people thought a channel was. It wasn’t just chat, it’s also a calendar, and we introduced a visual calendar system in our second year, where you could see a visual calendar of that channel’s activity. So people were like, oh great, every Monday morning I know exactly what’s going on for the rest of this week as it relates to this topic. So I do think that Slack’s kind of basics gave us the jumping off point to build some really cool stuff. Even if we wanted to build it, we wouldn’t have been able to recreate it, but seeing that it was there, it gave us just, you know, nice constraints to create some innovative stuff. 01:00:16 - Speaker 2: And certainly our experience on news and well you probably also can speak to this for other apps and companies you’ve been a part of, but, you know, the Apple platforms at this point, particularly the iOS, is just one of the most filled out in the w