EPISODE 1587

[INTRODUCTION]

[0:00:00] ANNOUNCER: Documentation is something that everyone knows is important but it's often difficult to get right. On software teams, good documentation can help to onboard new people, improve communication across teams and troubleshoot technical issues. When an application API or library is a commercial product, the quality of its documentation can determine whether it attracts users and succeeds on the market. 

GitBook is a popular documentation platform built with TypeScript and Node. It's found particular use among soft teams for creating technical documentation. Addison Schultz is the Developer Relations Lead at GitBook and he joins the show to talk about GitBook's development, software stack and how it's adding new integrations for VS Code, Slack and other tools. 

This episode of Software Engineering Daily is hosted by Sean Falconer. Check the show notes for more information on Sean's work and where to find.

[INTERVIEW]

[0:01:05] SF: Addison, welcome to the show.

[0:01:06] AS: Hey. Hey, Sean. Thanks for having me. Yeah, excited to be here.

[0:01:09] SF: Yeah. Thanks so much for doing this. Well, let's start off with having you introduce yourself. Who are you? What do you do? 

[0:01:16] AS: Yeah, absolutely. My name's Addison. I am running our developer relations team at a company called GitBook. Excited to talk to you guys a little bit more about what we're doing over at GitBook. But, yeah, I've started in late January this year. Mostly I've been focused on kind of building out our integration platform, which I'm also excited to talk a little bit more about later on in the show. And we launched that earlier this year back in May. And I think it was a pretty big success and people have been using it quite a lot. And we've already seen some pretty cool things being built from it. Yeah, it's been a pretty exciting ride so far. But I think we still got a lot more to do. 

[0:01:51] SF: Awesome. What's sort of the makeup of the developer relations team there? What organization does it sort of sit in? It can kind of sometimes fit within different departments and have sort of different areas of focus. It sounds like you're sort of focused on some of the platform part of it. Is it more on the engineering side? Or are you doing sort of more Dev marketing type of work as well?

[0:02:11] AS: I've seen it a couple different ways depending on the organization before. But here at GitBook, we are doing more like Dev marketing. The developer relations team is located under our marketing department. We have some content writers. We have a designer, head of marketing as well. But that being said, I think when you're working at a startup, it's pretty easy to have a lot of these more cross-functional roles in general. We're working pretty closely with our product team and engineering in general anyway.

[0:02:35] SF: Yeah, it makes sense. And I think DevRel teams typically are quite cross-functional, which is why you can – sometimes they're in marketing, sometimes they're in products, sometimes they're in engineering. Sometimes they're off on their own as well. It can be lots of different flavors. 

I want to get into some of the technical details about the integration platform that you mentioned. But before we go too deep, I think it would be helpful for anyone listening to this who maybe not fully aware of GitBook to have a bit of an introduction. What is GitBook? And what problem does it kind of help people solve? 

[0:03:04] AS: Yeah. Absolutely. I think that'd definitely be helpful. GitBook is a tool for technical teams to curate and produce technical knowledge. Whether that's through our Integrations, documentation. But pretty much just helping teams manage their knowledge across their teams. 

We've been around for a little bit as well. But our current product right now allows you to sign on. You have an editor you can start to create documentation. And you can also publish that documentation in a couple different ways. Whether that's under like a public URL. We also have some ways that you can protect it and put it under passwords and have some sign-in flows as well for the type of things that you're using. But we're seeing teams, yeah, use it for a lot of different types of things. 

When I say the word knowledge, I think a lot of people start to think directly about like documentation and stuff like that, which is definitely true. But we're also seeing teams start to use it a lot for things like internal knowledge bases, and company handbooks and even some kind of more random things like guides on programming or guides on designing. As long as you can publish it and want to like read information off of it, we're seeing people make something with it. 

[0:04:09] SF: What sort of, I guess, category of product would it fall into in terms of documentation? Is it a platform for like hosting your documentation or essentially just like actually generating the content, and managing it and then maybe hosting it in some other way.

[0:04:23] AS: Yeah. It is a tool where we also host it for you as well. You can hook up your own custom domains and everything. But, yeah, it's basically a SaaS product where you log in, you write the stuff there and then we'll manage the rest of it for you. Which is kind of interesting though, because on the other half of this, the integration platform that I was mentioning before is more of our kind of like open source solution for all of that. And the way that that ties into our product in general makes it a lot more I think – well, you can utilize the tool in a lot of new different ways based on, I mean, whatever your workflows are. I think that's pretty cool too.

[0:04:58] SF: Okay. Yeah. I definitely want to talk about that. I know with the sort of the history of GitBook, some of the things I read was it started as an open source project and then became a SaaS product a couple years ago with some open source elements. What were some of the challenges that the company faced with transitioning from open source to a SaaS product? 

[0:05:20] AS: Yeah. I think that can definitely be pretty challenging for many teams, especially if they're kind of so ingrained or started off in like the open source community. But as we started to transition from open source to SaaS, one of the main reasons that we wanted to kind of go this direction was to allow our team to start working and building a lot faster towards like the platform and the knowledge base that we currently have.

And that being said, we are definitely pretty big believers in open source in general, which is why we also focused a big part of the company on building and getting this integration platform up and running so we could still have teams and anyone using GitBook still be able to, yeah, kind of utilize it in the ways that they were maybe using GitBook in the past. 

It was a slow transition. I think we're still kind of slowly transitioning off in the background. Because where we are now as a SaaS product doesn't mean that we actually fully discontinued the old open source product. It's deprecated, but we still see people still using it today. 

[0:06:17] SF: Okay. It's deprecated. So you're not necessarily having to use resources within GitBook to like maintain it and continue to develop it. But some communities might be adopting it outside of your company that are leveraging it in different ways. Is that right? 

[0:06:33] AS: Yeah. Yeah. That's true. 

[0:06:35] SF: You mentioned the integration platform. Integration, as I understand it, it helps teams or developers extend the default functionality of GitBook by apps that levers the API. I guess, first, what are some of the experiences that someone can create using the GitBook API? And is this primarily about creating new experiences within GitBook or for pushing information from GitBook to, say, like an external service? 

[0:07:04] AS: Yeah. The integration platform allows you to integrate with other workflows or other tools inside of our app. When you log into GitBook or you publish a site, let's take our own documentation platform. For instance, we have it under docs.gitbook.com. 

We have different types of Integrations that we've built internally that allow you to display information from other resources. For instance, any of like a product demo type of integration where you'll have product walkthroughs. You can include those right in your docs. We have plenty of different Integrations for things like analytics. 

But also, like I was mentioning, there are teams that are using GitBook for more than just public docs. They're using for like internal knowledge bases and workflows. We do have Integrations with other tools, for instance, like Jira or Linear, which allow teams to embed like issues and work and use it as more of like a workspace in that manner. 

There's also a bunch of other ones that are kind of like one-off, but allow you to maybe send messages to Slack or send messages to Discord when things are updated using webhooks and specific part of the platform in that way. 

[0:08:09] SF: Some of these Integrations that you mentioned, I guess, who built them? Were they built by GitBook or these third-party contributions?

[0:08:17] AS: Yeah. We have launched the integration platform earlier this year in May. And before we had launched it, we had a team internally building I think maybe 10 to 12 of these main in-house integrations. And based off that, we started to put together a bunch of resources on how to build this type of integration. 

And since then, we've seen some other teams start to pick it up and build their own versions of the for their different tools or whatever tools that they want to use. But that being said, our integration platform doesn't necessarily mean that it's always public. 

Integrations as well. There are I think a lot of teams using it for private workflows or just kind of in ways that are helping just them and their organizations and aren't necessarily things that they're going to publish to our marketplace, et cetera.

[0:09:05] SF: Right. If you're using this primarily for internal technical documentation or internal knowledge base development, then it probably doesn't make sense to necessarily create an integration that you just make available to anyone. 

[0:09:17] AS: Right. And there's also two a couple different pieces of our platform. In a nutshell, there's three main part pieces. We have the custom integration section, which is kind of what I think I've been focusing mostly on. Those are the things that if you are in GitBook or you're on a published site, you'll see them. You'll insert them into the page and you can interact with them and et cetera. 

The second piece is the visitor authentication piece, which is basically allowing you to set up a custom way to protect and make users log in before they access the documentation or publish site. And the third one is then our REST API, which is basically it's kind of fueling the integration platform. But you can also use it completely standalone outside of it. And it allows you to read data and push data in. There's I think a lot of different possibilities and a lot of things that I'm excited for more teams to start using and building.

[0:10:08] SF: Okay. It sounds like there's sort of three different flavors of integrations. You can essentially create an integration that maybe embeds something directly into like a GitBook page. There's a version where essentially you can hit REST API endpoints. And then – now I'm forgetting the third version. But, essentially, there's these different integration points that someone would use in order to create these different – support various workflows and extend the default functionality of GitBook. 

[0:10:36] AS: Yeah. That's right. And I think having these three different pieces makes it a lot more powerful. Because you can kind of – you're not really siloed into using one or the other. You can pick and choose the pieces that make the most sense to you. And I think it also makes it a lot easier to integrate with existing workflows, especially if you're doing a lot of like CI/CD stuff, which is super popular with teams who are generating or working on documentation. Keeping the docs as close to like the source as possible. And through using a combination of these different tools, it makes it possible and a lot more easy.

[0:11:07] SF: Okay. And then in terms of the integration platform, how did this project sort of come together? What was the Genesis of the idea to create an integration platform in a marketplace? And how long did it take to go from concept to launch? 

[0:11:19] AS: Yeah. As I kind of mentioned before, we come from an open source kind of background. And we've been transitioning over to this SaaS product or this online product. And having an integration platform I think has always been on the cards for us. As we made this transition to the SaaS product, were like, "Yeah, we need to have this integration platform." Because all the things that we might be taking away from an open source perspective, we want to give back and make sure that teams are still able to do X, Y and Z with our new product as it continue to transition and continue to use it. 

It's like the birth idea had always been there. And we started building it as soon as we started building the new product. But we had it in beta for a while when we launched the new product. And the integration platform then came out of beta a few months afterwards. And it went pretty fast, I would say. I wanted to say maybe about 6 months before we had fully launched it. But that includes kind of everything, which are things like guides, examples, the API, Node.js wrapper, the custom block SDK, which is the things that we were talking about before. And that's also coming out of beta. So we had a lot of you know feedback coming in and out and working with different users who are interested in building on top of it and kind of a big ecosystem of continuing to build on it. 

Yeah. Now that even though we're out of beta now, it doesn't mean necessarily that we're done working on it. Because we still got a lot things that, well, I'm excited about us to continue launching.

[0:12:46] SF: Mm-hmm. Yeah. Of course. How many people were involved with the project from the beginning? 

[0:12:51] AS: It's been around I think a team of four, which is I would say like three engineers and myself have been really focusing on this since its birth. And we're a pretty small team at GitBook in general. I think our headcount right now is about 30. And we've always been a pretty small organization in general. I'm pretty happy that we were able to get, yeah, enough resources to focus on this.

[0:13:12] SF: Okay. And then you had to – you developed APIs, CLI documentation. Probably a bunch of other things as well. Were these all new projects?

[0:13:24] AS: Yes. Everything was brand-new. And, essentially, all of the integrations that we have – we built for like this launch also were built on top of the platform in general. There was a lot of kind of building kind of endpoints for different things that we need. As we would like come along, we'd start building integration, say, "Oh, we actually need this in order to finish it." There was a bit of that. 

But I think we did a pretty good job overall planning on how we wanted this to look and how we wanted it to behave and interact with the tool. There wasn't a whole lot of that in general. And then, yeah, on the other half of it, like building all of the examples, the guides, videos and stuff like that. That was all new, but coming afterwards after we had it in a bit more of a stable place.

[0:14:07] SF: Mm-hmm. And then was that your main role, was sort of putting together the explanatory education material? 

[0:14:13] AS: Yeah. That was the main focus. And kind of getting the integration platform out of beta. When I joined, we had just launched the platform into beta. We had, again, these like 12 integrations. Not a whole lot of documentation. Yeah, no examples, guides, et cetera. My main kind of focus for those first couple months was getting it all into a usable and reliable state with the team. 

[0:14:37] SF: Teah. And I'm sure that has a big impact in terms of ad option. Because you could have a great platform. But if no one understands how to use it, then it's not going to really necessarily go anywhere.

[0:14:48] AS: Yeah. Absolutely. And I think it's pretty fun. It's been something that I've been really focused on in other developer relations teams over the last couple years. And I think it's pretty rewarding being able to kind of take a platform that's there and workable. But figuring out, "Okay, what do people want to build? How can we build this stuff? And what's missing if we want to kind of take it to the end?" And you get to play around with a lot of things and make a lot of proof of concepts. And, yeah, tie it all up if you find something that works. 

[0:15:14] SF: And what were some of the tough decisions that had to be made along the way? Maybe on the product, or engineering side, or design side, or maybe even in some of the things that you were working on in terms of getting this beyond beta into being like a real productionized product. 

[0:15:30] AS: I think there's always a bit of a balance when you're building something new, especially when you take a look at it from your existing and current user base. And this also applies to a lot of the decisions that we had to make I think as we were transitioning out of open source as well. I think we did a pretty good job at like focusing on what our current users and customers were asking for. 

And I think our community of GitBook users has always been pretty reliable and pretty open and receptive to helping us out with like the different types of feedback. Yeah, we were able to kind of build it in a good way that was tested out by our users quite a lot. And they were able to pick it up quite fast. 

I think what's also pretty helpful was we did have one person on our team that was focusing a little bit more, I would say, on some of the requests or things that our current existing customers were asking for. We always had that workflow in place where we were able to continue working on things that our customers are asking for.

[0:16:26] SF: Was there any sort of, I guess, assumptions or maybe mistakes that were made along the way that you had to maybe go back to the drawing board or think through? 

[0:16:35] AS: One thing that we realized a little bit later on or like in the middle, let's say, of building this out is that we should have been adding a little bit more endpoints or a bit more of a focus on like user authentication and more like admin kind of things. 

And this is the thing that I was kind of talking about before. Because I think when you're talking about an API endpoint that allows you to add/remove users, that doesn't necessarily cater to most of the user base that you might have because they're working on one or two people organizations. But it's a really big piece that comes in for larger organizations because they need these type of tools in order to manage like their members and et cetera. 

We had a few of these endpoints in the beginning, but I think we had realized that we needed to focus a little bit more on that and add a few more towards the end. That was maybe one thing that I think we should have done a little bit earlier on, but it was nothing too bad. And I think there was only like two or three different end points maybe that we ended up building past the initial planning anyway. 

[0:17:35] SF: What's sort of the makeup of the – I don't know. The customer profile of people using GitBook? Is it enterprise as well as startups? Or is it predominant on one side? It sounds like you had to build in some of this off-modeling to cater to perhaps a larger company that's a little bit more security conscious.

[0:17:54] AS: Yeah. Yeah. Exactly. I would actually say that our makeup of our user base is mostly kind of around these startup scale ups. But we do have a handful of names that are a bit bigger that require a few more of these more in-depth security solutions. But I think that's kind of the way it goes especially when you're talking about a documentation platform. Because the tool, GitBook itself is extremely easy to use. And for someone who's maybe not so technical or for teams who need to get up and like start up super-fast, it's really easy for anyone to sign up, start typing. 

We also allow you to start from a number of different sources, which is super nice. So you can import your docs from pretty much anywhere as long as it's written down. But one of my favorite features that we have at GitBook is one we call git-sync, which allows you to sync a GitHub or GitLab repository with GitBook. 

If you already have some sort of docs up and running, you can automatically import that and sync it with GitBook. But the cool part about it is it actually goes both ways. If you do make a change in GitBook, it will also reflect that change in GitHub or GitLab afterwards. As your team builds, your developers could – if they're adding docs to your pages, they can continue working in their IDE or wherever they are used to be working. Tech writers, whoever is managing more of like the customization and the look and feel of it, can work in GitBook and it's all going to stay in sync.

[0:19:17] SF: And then you mentioned importing. You mentioned two specific use cases around like GitLab and GitHub. But if I did something more bespoke where maybe I had my own sort of like knowledge base system with a bunch of HTML pages, is that something also that I would be able to import if I wanted to sort of modernize or maybe come up with a better approach to managing my internal and external documentation through GitBook? 

[0:19:41] AS: Yeah. We would support, I would say, most of the popular solutions for displaying text. If you're importing a file, we support markdown files, Microsoft Word, Confluence, HTML, Notion, Google Docs, Quip and a few other types of things as well. We are able to kind of parse whatever you're adding in there. 

For instance, even if you have like an open API spec and you upload that to GitBook, we'll recognize that and start to fill it out not with like the text but with the open API blocks at allow you to see the requests coming in and out. 

[0:20:17] SF: Can you talk a little bit about some of the API design choices that were made around authentication model? REST versus GraphQL. There's a lot of decisions that you have to make when you're designing an API that's going to be – it's a public API that's going to be consumed by, hopefully, your customers. What were some of those design choices that were made?

[0:20:38] AS: Yeah. I mean, one of the most interesting parts that you even just mentioned is the OAuth, which is something that we don't current have but we do want to. But I think we hadn't implemented that at first just, again, kind of in light of working a little bit faster and getting to like this initial launch. But it's definitely on our radar to implement soon. 

Yeah, the rest of it I think had kind of come from more of a place of familiarity, but also thinking about how we wanted others to start using it and interacting with it as well. 

Specifically, one thing that we had always wanted to do – so we have our REST API, which is just a standard REST API. But then on top of that we have, again, the integration platform that I was mentioning and the custom block integrations. And then we also have Node.js wrapper as well. And both of those two things are built on top of our REST API. 

Before we could get to that, we wanted to make sure we had like a pretty stable REST API in general. And I would say the main focus and decisions that we had were on like the technologies that we were using for like these SDKs or the wrappers around our REST API. 

Our entire product is built in TypeScript and Nodes. Basically, we wanted to start with that, essentially, again, for us to start building and helping other people get started. But yeah, I think that's a little bit more about kind of how we started to design it. I think to, be honest, we have quite a lot more that we need to do or we have a long ways to – a lot more stuff to support. But I think we started off in a pretty good spot.

[0:22:10] SF: And then you mentioned the Node wrapper, Node SDK, is that something that's autogenerated, or is it handcrafted, or some sort of combination?

[0:22:19] AS: Yeah. It is handcrafted and not necessarily autogenerated mostly because there's also a few endpoints that are internal kind of things only. And before we put a final endpoint into our docs and make it more public, we also test it out quite a bit and make sure that we have the right design choices behind it on the types of things that you're passing to the request and the type of things that you should expect to get back. That's why we kind of handcraft it a little bit. Well, like pick and choose, let's say. Or like we build it from the thing that we have.

[0:22:51] SF: And then you started with Node and TypeScript, but are there plans to expand to supporting other SDKs? And I guess where's that sort of fall into the list of priorities? It sounds like you have a platform, but like anything, like any product, there's lots of things to do. I guess what is sort of the vision for – I don't know, the future of the SDKs? 

[0:23:13] AS: Yeah so one thing that I think – it's a pretty interesting question. Because I think when you take a look at how we have kind of started off and seen people start to use GitBook, it's been very heavy on like the documentation or the public-facing kind of aspect of our tool. And having a lot of these like visible elements to our integration platform was a pretty logical choice in that regard. So, you can embed things or you can touch things and interact with them and see them on the screen. 

But one thing that we're starting to see and starting to do as a company is actually realize that there's a lot of companies that are using GitBook to curate our knowledge, their knowledge, and start to use it as more of like a database in that sense. I think more of our focus is going to be on supporting different workflows or different technologies that'll allow teams to, I guess, consume this knowledge in GitBook. I think it's going to be a lot less focused on UI-type technologies and a little bit more on like technologies that might be good at importing or technologies used across the board in other tools. 

I think it's actually going to be a lot of using Integrations with other integrations platforms. For instance, like maybe using Notion's API or their integration platform and tying that up with GitBook in order to make like a connector to import a lot of their knowledge into GitBook. 

[0:24:34] SF: Okay. Yeah. Basically, helping serve as like the backend to platforms like a Confluence or a Notion. 

[0:24:42] AS: Yeah. Yeah. Absolutely. One interesting part about it as well that I think is a cool possibility for teams using GitBook as well is we've, over the last couple months, also introduced our GitBook AI, which allows teams to basically ask questions against their GitBook database. 

And I think as we've started to release that, we've seen more teams like having more of a need to have more of their stuff in GitBook. And that's pretty interesting because I think it expands a lot past just traditional documentation. Something that we're actually releasing this week, which is pretty interesting, is another integration for GitHub, which allows you to index and import your issues, comments, pull requests and just general metadata about specific repositories that you granted access to. But instead of displaying that information inside of the docs, for instance, you'll be able to use the GitBook AI assistant to ask it questions about like your workflow or the technical setup that you might have. Like, "Who made this pull request?" Or, "What are the most critical five open issues that I could work on?" And I think for onboarding teams and technical teams in that regard, it's going to be pretty useful. That's kind of where I think we're starting to put a little bit more of our focus, specifically with the integration platform.

[0:25:56] SF: Okay. And then the GitBook AI, how does someone consume that? Is that essentially an API endpoint that they're using? 

[0:26:04] AS: Yeah. Right now, it's only enabled for specific teams. I believe you actually have to be like on one of our pro plans in order to enable it for the space that you're using. But, for instance, we've already have it up and running on our documentation platform. If anyone would go to docs.gitbook.com, we have a little search bar in the upper right-hand corner. And right now it's branded as lens, but I think that might be changing kind of soon. 

But if you click the lens section, you can start to ask any questions about our current documentation published platform. We do have a couple like prompts that it generates for you. But for instance, even on our integration platform, we do have like different boiler plates snippets. But you could say, "What does an example index.ts file look like if I want to build this type of integration?" And it should be able to spit out basically a file for you on how to use it.

Starting there, from like documentation and then, again, being able to add more sources from teams that are like specific to their workflows and more technical knowledge, that's where I think we see where GitBook can provide a lot of value.

[0:27:07] SF: Yeah. Absolutely. And then what is the sort of under the hood in terms of the AI tech stack? Are you using LLMs? Or are you taking advantage of other NLP methods for detect, intent and create responses? 

[0:27:21] AS: No. We are currently using LLMs. I believe we're using Open AI right now. But I do know that there is a team at our company that's kind of looking into expanding on that offering and kind of figuring out if there's better ways that we could be using this or diving a little bit deeper into it.

[0:27:36] SF: Okay. And then I guess you may not know this, but I'm just curious for something like the GitHub integration into your AI product that you mentioned. I'm assuming then that since you're using an open AI model behind the scenes, you're creating some sort of like embedding model or essentially a rag model on top of that using whatever the local data is available from the customer in order to augment the inference engine. Is that right? 

[0:28:04] AS: Yeah. I don't know the whole specifics about it, but that is essentially how it's working also currently right now with our current product. Again, if you're like asking a question in our docs, docs.gitbook.com, it's only going to be giving you kind of resources and answers that are related to that or depending on like wherever you're at.

[0:28:21] SF: Okay. Let's go back to talking about the integration platform. Let's say that I want to build an integration. Can you kind of walk me through the process of building maybe something like – essentially, the "Hello World!" version of an integration using the integration platform. 

[0:28:38] AS: Yeah. Yeah. Absolutely. As mentioned before, we have kind of three different pieces of it. But I'll kind of give you a walkthrough on how you could build an integration that you could insert into a GitBook document. So you could see it, you can click on it and interact with it. 

If you are starting, well, first off, you probably want to head to our documentation. And that specifically is going to be under developers.gitbook.com. And that's where you'll find all the docs for our integration platform. And to start, we do have a CLI tool, which allows you to bootstrap your first integration. And also, what I recommend if you're also starting off on a new one, just because we tend to update that with updated starter kits or endpoints and things that might be relevant if you're using it in the future. But after you get that, essentially it will give you a – well, just like your source folder, wherever you create it. It will install dependencies. 

And then from there, we've also created, as part of our CLI, a tunnel that allows you to say when you're in GitBook, when you have a GitBook page open, you can say, "Hey, I want this integration that I'm building to actually be the one displaying here." Otherwise, you would have to publish it, publish it to the marketplace or publish it to our platform. Install it and then you would be able to see it. But without the tunnel, you wouldn't be able to see these updates that are coming through if you're making changes locally. 

After you run the command, it's GitBook Dev and then you give it a ID of the space that you're working in. It'll connect all the traffic between your local version of it and the one that's on there. And that's pretty much it actually. It's pretty straightforward and pretty fast. 

I've also been focused on getting a good like boilerplate that kind of demonstrates all of the main features and functionalities that you would or should probably be using when developing integration. Also, there's plenty of guides. But that's I think a good starting point if you're building your first integration.

[0:30:30] SF: And then in terms of building integrations that eventually I'm going to move into my production version of GitBook, is there like a staging environment that I can use in order to like essentially actively develop this to the point where it's ready to go be published live to the rest of my company or potentially customers? 

[0:30:51] AS: Yeah. We have a couple different ways that you can configure the integration that you're working on. When you first create this integration, we generate what's called a manifest file or the GitBook manifest, which is just a YAML file that describes how this should behave, who owns it, et cetera. 

And one of the keys there is the visibility. And we have a couple different ones. We have private, unlisted and public. When you start off, it's private by default. And that means it's only available to you and your organization. But then that also means that nobody else can install it unless they're a part of your organization. Even if somehow someone found it or they tried to install it, it just wouldn't work. 

But then if you are interested in sharing it, let's say, elsewhere, sharing it with someone outside of your organization, you would set it to unlisted. And that way you would be able to share the URL installation link with anybody. They can install it. They can use your integration. But we also do have our public marketplace, which you'll find in our actual app. And you'll also find it on our website, just gitbook.com/integrations. 

But in order for it to be visible there, you do have to change it to public and then also submit it through our marketplace submission, which is where myself and my team will go through. We'll verify. We'll ask for a few other things and go through different versions of the code and just kind of make sure that it's suitable for both our platform and for users as well. If you're looking at any of those that are on the integration marketplace, those have been already through our marketplace submission process. 

[0:32:23] SF: Yeah. You mentioned the marketplace. As a developer, if I was interested in building integrations for GitBook and customers of GitBook and then publishing those to the marketplace, is that something that I can make money off of? Is there like a rev share model set up? Something like Shopify, or even like Apple Store, or something like that? 

[0:32:42] AS: Yeah. Right now, we don't have anything at least natively that you could make like money off of our marketplace. But I think it's something that I'd definitely be interested in kind of spearheading at the company. It's also something I've seen on a few other organizations I've worked at. And I think it's a pretty good way to get developers using your product, but also building meaningful things on your platform. 

I just think we're still a bit young, let's say, in our integration journey. That it's not necessarily the biggest priority right now. But that being said, I think there are still some ways that interested developers could figure out how to do this. And it's essentially kind of like gating off the use by maybe building a screen in the integration that says, "If you want access to this, you have to sign up or pay," et cetera. It would be a lot more overhead on the developers to kind of manage and maintain licenses and all of that kind of stuff. But it would be possible, I would say, through that kind of workflow. But I think, hopefully, shorter to medium term, we can try to figure out something that's useful for developers if they're interested in making a little bit of money off this.

[0:33:46] SF: Yeah. Fair enough. And then when it comes to developing an integration, if I'm doing this for the first time, are there certain things that I should be aware of? Like little tips and tricks that might ease my experience? 

[0:33:59] AS: Yeah. I think the biggest thing that I would recommend for anyone who's interested in building on top of the integration platform of GitBook is mostly kind of to understand GitBook as a product mostly because there's two different sections of it in a sense. You have your editor, which you can edit your documentation. But you have your published site as well, which is accessible by anyone. And your integration can live in both environments. It's kind of understanding the life cycle, let's say, of like a GitBook page and the life cycle as your integration and how it interacts with both of these different environments is something that I think I would recommend for people to kind of read about, which we do have, again, in all of our docs as well. But I think once you can understand it, it'll allow you to kind of boot up this local environment a lot faster and kind of understand how different pieces of our API are working with each other and how they're interacting with the GitBook app in general. 

[0:34:56] SF: Okay. Fantastic. And then as we start to wrap up, what's coming up at GitBook? Is there anything else that you'd like to share? 

[0:35:03] AS: Yeah. I think the biggest thing that I'm excited about is something – and I kind of hinted at a little bit before, specifically with like the GitHub integration that we had just just created. But in combination with that and, again, kind of following the reasons that we started to build that integration, again, helping teams curate their knowledge in the sources that they're working on and bringing all of that back into GitBook. 

We've also been working on a few other integrations that are in kind of different product areas, but all kind of going towards the same goal. We're also releasing an extension for Visual Studio Code and an extension for Slack that do two kind of different things but, again, in the same vein. 

The Visual Studio Code integration allows you to actually curate and record videos. And it watches kind of the different files that you save or highlight and it actually puts that into kind of a more human-readable, digestible abstract for like a read me. You can kind of think of like a loom, if you're taking a loom of something. But it also will include like code snippets and things like that. And then it also will put that into your GitBook after you kind of take a look at it and go through it.

And the other thing that we are also releasing is the integration for Slack, which allows you to do something similar, but call the GitBook Slack bot inside of different threads that you might be working in. We do it all the time at GitBook. And I've been in a lot of other organizations that work in pretty similar ways. But I'm sure you've probably seen it where you open up Slack and you have 50, 60 Slack messages. And there's some sort of decisions that are made in and out of there or crucial information. 

But our Slack bot will go through – kind of at all of that. Kind of discard any of the things that don't make sense and add all of that to your GitBook as well for you to reference and use later on. I think we're still pretty early days at figuring out the best way that teams are going to start using this, but ourselves included have been finding a lot of value out of this. I think we're pretty excited to see when this kind of hits the market. Yeah, we're just actually opening up our beta tomorrow. By the time you're listening to this, I'm sure you'll be able to find our beta pages and see a little bit more about it.

[0:37:13] SF: Oh, wow. Yeah, that's very cool. I mean, I'm game to try anything that will help me organize my Slack and streamline the process of essentially prioritizing what I need to do. Awesome. 

Well, Addison, thank you so much for being here. This was really fun. What's the best way for anybody to listening to this that's interested in learning more to get a hold of you or someone at GitBook? 

[0:37:33] AS: Yeah. Absolutely. If you're interested in learning more about GitBook in general, feel free to head over to our website or our documentation. But myself personally, I'm around on Twitter, LinkedIn. And I'm more happy to connect and chat with anyone who's interested about learning about GitBook, the integration platform, DevRel or just really anything else. So, I'm an open book. And feel free to come on the internet and say hi.

[0:37:55] SF: All right. Thank you. Awesome. Thanks for being here. Cheers. 

[0:37:58] AS: Yeah. Thanks for having me.

[END]