GitHub Start Up Wednesday with Danny Sheridan and Fern

12 Dec 2024 (6 days ago)
GitHub Start Up Wednesday with Danny Sheridan and Fern

GitHub Startup Program and Introduction of Fern

  • GitHub Startup Wednesday is a space where innovators building in the startup space are celebrated, and GitHub is grateful to support startups with its program, which offers not only credits but also a great community and network (1m51s).
  • The GitHub Startup Program provides Enterprise licenses, Azure credits, and other benefits, but its value goes beyond these offerings, with a network of founders, connections, and a team committed to making startups successful (2m6s).
  • Startups can apply for the program by checking the link on the screen, which includes details about the offering and the application process (2m41s).
  • Existing startups using GitHub are encouraged to give a shout if they would like to be featured on the show, which has a broad variety of companies, including those with open-source involvement (2m56s).

Fern: Overview and Operations

  • Danny Sheridan, co-founder and CEO of Fern, is a special guest, and his company is from the Y Combinator class of W23, aiming to make it easier for companies to offer best-in-class SDKs and API docs (3m35s).
  • Danny spent three years at Amazon and AWS, where he saw the company build internal tooling to generate SDKs in popular programming languages and maintain them in the API reference (3m45s).
  • Fern is based in Brooklyn, New York, and has under 20 people, making it an exciting time for the startup (4m11s).
  • Fern is a startup with under 20 employees, and the entire team works from an office in the Williamsburg neighborhood of Brooklyn, New York, to build a developer tool company, taking advantage of the exceptional talent pool in the area (5m28s).
  • The company typically hires software engineers with six to eight years of professional experience and currently serves over 125 customers (5m53s).
  • Fern uses Slack channels to communicate directly with customers and prospects, with over 200 channels, allowing engineers and the sales team to have direct access to customers (6m9s).
  • The company has a community Slack channel where users can join and participate in public channels, including a contributions channel where users can help improve Fern's open-source project (6m43s).

Fern's Solution to API Development Challenges

  • Fern aims to solve problems in the API development space, drawing from the founder's experience working at AWS and observing the complexity of AWS's public APIs for interacting with various services such as S3, EC2, and DynamoDB (7m48s).
  • The founder notes that each AWS service builds its API first, assuming it will be a public-facing API endpoint, and Fern aims to make API development easier for users (8m30s).
  • To ensure a good developer experience, consistency in naming conventions across APIs is necessary, and standardization should be maintained, especially when dealing with multiple services like AWS, which has over 300 services (8m35s).
  • A central team should not be responsible for releasing new APIs, as this would slow down the process, and teams should be able to iterate at their own pace, especially with the availability of AI foundational models like Bedrock (8m53s).
  • Typically, when a public API changes, it opens a ticket that goes through various teams, which can cause delays in updating SDKs for different programming languages, resulting in a frustrating experience for developers (9m23s).
  • Many developers, especially junior ones, prefer to use SDKs over making direct API calls, and there are more SDK languages to support than ever before, making it challenging to staff an engineering team to cover all languages (10m9s).
  • To address this issue, AWS built an automated code generation system, which reads an API definition and outputs SDKs for various languages, available on registries like npm, pip, or Maven Central (11m6s).
  • This solution helps manage the generation of SDKs across different languages, maintaining quality, building, and versioning as they change over time (11m33s).
  • Other companies, like Palantir Technologies, have also built internal solutions to address this problem, such as Conjure, which is open-source, similar to AWS's Smithy (12m20s).
  • The pattern being looked for is finding big companies that have encountered a problem and built internal tools, then creating a generic SaaS B2B product from that solution (12m59s).
  • Companies like AWS, Stripe, Dropbox, and Twilio have built internal tools to solve this problem, with some of them open-sourcing their solutions (13m15s).
  • The challenge is to build a generalized solution that would cause companies to stop maintaining their internal tools and instead use a reliable and battle-tested vendor (13m50s).
  • The need for this solution is not limited to big companies, as smaller companies also struggle with the same issues (14m13s).
  • Many startups, including those in the Y Combinator accelerator program, struggle to build and document their APIs, as well as create SDKs, before launching their products (14m26s).
  • Stripe has raised the bar for developer experience, with well-documented services and SDKs in popular programming languages, making it a model for other companies to follow (15m51s).
  • The goal is to provide a solution that allows companies to quickly and easily create API documentation websites, SDKs, and other developer tools, even on a tight timeline (15m39s).
  • Fern is a tool that helps small startups compete with larger companies by providing them with limited engineering resources, allowing them to go live quickly and efficiently (16m49s).

Fern's Open-Source Approach and Customer Success

  • A company reached out to Fern a couple of days prior and was able to go live, with Fern being able to share their documentation and give a shout-out (17m2s).
  • The company that reached out to Fern is Scrappy Bara, and their documentation includes an API reference (19m32s).
  • Fern was built as an open-source tool to ensure that users have a backup plan in case the company doesn't work out, allowing them to poke into the code generation process (17m56s).
  • One of Fern's customers is Square, a fintech company that uses Fern to power their SDK Suite, generating hundreds of thousands of lines of code in each programming language (18m24s).
  • Fern has bought into the GitHub ecosystem, using GitHub for startups to contribute to their project, and all of their documentation is written in markdown (18m47s).
  • The whole Fern team, including non-technical folks, is able to contribute to their project and documentation, which is a team effort (19m1s).
  • Fern's approach to collaboration is to have everyone on the team contribute to the documentation, regardless of their role, using a flavor of markdown called MDX (19m7s).
  • A service's documentation is described, including on-page feedback and the ability to enter an email address, with the documentation being built with Fern, allowing users to write markdown content to power guides or tutorials, and featuring API reference with different endpoints (19m51s).
  • The documentation of a customer named Human Loop is showcased, highlighting their use of versioning, which allows them to update their documentation without losing previous versions, and their API reference includes TypeScript and Python SDKs with usage instructions (20m29s).

API Development and Developer Experience

  • The transition of startups from being API-first to SDK-first is discussed, resulting in faster integration time with fewer errors and frustrations for developers, and an example of an API endpoint is shown, using an OpenAPI specification to describe a REST API (21m5s).
  • The API endpoint example features nesting of objects, which Fern handles well, and includes code examples in different languages, such as TypeScript and Python, using the client library or SDK, and also shows a generic HTTP request in Java (21m27s).
  • The goal of Fern is to make it easier for developers to integrate APIs, following best practices, and a demo is about to be shown, featuring the artifacts of one of Fern's customers, using Webflow as an example (23m7s).

Webflow Integration and Demo

  • Webflow is a customer of Fern, and they make it easy to build a website, with the demo aiming to show what comes out of Fern by looking at Webflow's artifacts (23m30s).
  • Fern is working on a new website using Webflow, which provides a nice landing page and allows users to explore APIs, including Fern's developer documentation product, Scrappy, Human Loop, and Webflow. (23m43s)
  • Webflow has an API reference that provides an introduction for developers and allows users to see a demo of Fern, including a documentation website that is hosted. (24m2s)
  • To access the API token in Webflow, users can provide their API token, but this process can be complicated and requires multiple steps, including searching for the token on Google and navigating through multiple tabs. (24m29s)
  • Fern has improved the developer experience by adding a login button that allows users to easily authenticate and access their API token, which is populated automatically. (25m14s)
  • The authentication process is handled through a JWT, which returns a payload to populate the API token and other fields, such as the site ID. (25m44s)
  • Users can make API requests in a no-code way using the API token, and can also copy the code to use in their own projects, such as in TypeScript. (26m10s)
  • Fern's vision is to create a similar experience to Postman, an API testing tool, where users can turn an API request into a form and make requests within the documentation. (26m43s)
  • Fern can handle multiple programming languages and SDKs, including JavaScript and Python, and can autogenerate usage documentation, exception handling, and error handling for developers, with the goal of eliminating the need for an SDK engineering team (27m38s).
  • Webflow uses Fern to generate and publish SDKs in multiple programming languages, with over 20,000 weekly downloads, and Fern also documents the SDKs in Webflow's documentation (28m0s).

Fern's Impact on Webflow's Ecosystem

  • Fern helps lower the friction required to build plugins on top of Webflow's ecosystem, leading to a proliferation of plugins, and this strategy has been successful for Webflow's business (29m48s).

Fern's Application in Fintech with Square

  • Fern's customers include developer tool companies like Webflow, but also companies outside of the developer tool space, such as Square, a fintech company that uses Fern to provide data to third-party developers and integration partners (30m30s).
  • Square uses Fern to provide data to companies like QuickBooks and to help restaurant owners aggregate data from multiple locations, and Fern helps Square to document and provide access to this data (30m50s).
  • A customer may want to integrate their Square account with other services, such as Tableau or accounting software, and apply for a loan, which requires integrating with Square's API or SDK for a more successful and faster process (30m59s).
  • Using an SDK can reduce the need for support, accelerate time to build, and allow developers to build in an afternoon without waiting for a reply from a support email address (31m18s).
  • Square's SDK has the Fern API bot, which regenerates and pushes code, and an engineer on their team also contributes code, demonstrating the ability to augment generated code with custom code (31m57s).
  • GitHub workflows are included in all of Fern's customers, automatically generating a repository for Square and relying on GitHub workflows throughout the process (32m22s).
  • The Fern ignore file allows developers to add handwritten integration tests, webflow helper methods, and customize their read-me, enabling generated code to live in harmony with manually maintained code (32m48s).
  • Fern's ability to work with Square, a company that processes financial transactions, speaks to the trust and security of the firm's APIs, which have hundreds of endpoints (33m33s).

Choosing the Right API Approach

  • For those new to building APIs, the question of whether to use REST or another approach, such as SD, is a common one, and the answer depends on the specific situation and the goal of enabling developers to build with a product or integrate into a platform (34m13s).
  • The choice between SDK and API depends on the situation, and considering how to enable developers to build with a product or integrate into a platform is an important part of the decision-making process (34m30s).
  • When building an API, there are three common options for API protocol: REST (HTTP), GraphQL, and gRPC, with the choice depending on the specific needs of the project (35m0s).
  • gRPC is the least likely to be selected and is typically used for internal service-to-service microservice interactions that require high performance, such as processing large amounts of satellite imagery data (35m23s).
  • GraphQL is often used for front-end development, connecting to backends, and is typically used to appease front-end developers, but it can have a steep learning curve and is rarely used for public APIs (36m11s).
  • More than 90% of API calls between companies are happening via REST or HTTP calls, with GraphQL not being widely adopted for public APIs (37m11s).
  • When deciding which protocol to use, it's essential to consider whether the API is for internal or external use, with external APIs requiring a higher level of engineering excellence (38m1s).
  • Assuming an API will be external from the start can lead to better design and engineering practices, similar to building an open-source project (38m16s).
  • Companies like GitHub and Shopify have experimented with GraphQL for public APIs, but it's not a common practice, and most companies, including those in the Y Combinator Fall 2024 batch, use REST for their public APIs (37m41s).
  • When building an API, the first question to ask is whether it's internal or external, and if it's external, REST is often the best choice, with the Open API specification used to describe how the API works (38m35s).

Fern's Evolution and Customer Focus

  • GraphQL is also an option, but it has limitations, and API documentation is crucial, which is why Fern focused on having an API documentation builder (39m15s).
  • Initially, Fern didn't plan to build API documentation, thinking it was a solved problem with existing solutions like Docusaurus, Astro, ReadMe, and others (39m35s).
  • However, customers kept asking Fern to provide API documentation, wanting a single vendor to solve both documentation and SDK problems, with the same source of truth as the Open API specification (40m7s).
  • This led Fern to learn that customers prefer to interact with one software solution to achieve their desired outcome, rather than having to make multiple vendor decisions and go through security reviews (40m30s).
  • The approach of working backwards from what the customer needs, as practiced at Amazon, is key to Fern's success, with the goal of making developers successful and helping them get started quickly (41m0s).
  • Fern's ability to capture a specific need in the market has contributed to its success, with the company growing from four customers to over 100, and continuing to expand its access to problems in software companies (41m59s).
  • The company prioritizes customer feedback and selectively chooses which ideas to implement, with a focus on what customers want, as seen in the decision to build a feature that was a repeated request from customers, specifically having their documentation and SDKs accurately documented, matching their brand, and being selective in implementing customer ideas (42m36s).
  • The company uses GitHub issues to track customer feedback and requests, allowing them to see what customers want and prioritize accordingly (43m17s).

Fern's Open-Source Community and Contributions

  • Customers, potential customers, and job candidates can view the company's codebase to see what they're working on, with over 6,300 commits to the project so far, and contributions being made every couple of hours (44m6s).
  • The company has a public repository on GitHub, with nearly 1,200 releases, and 86 contributors, including external contributors, showing that the project is actively maintained and open to contributions (44m35s).
  • Those interested in contributing to the project can start by looking at the GitHub issues, specifically the "good first issue" label, which provides a starting point for new contributors (45m31s).

Fern's Transition to GitHub Actions

  • The company has migrated from CircleCI to GitHub Actions for their CI/CD pipelines, allowing for greater visibility into the pipeline and tests, and is now paying a monthly bill for the service, which is seen as a necessary part of running their service (45m41s).
  • The decision to transition to GitHub Actions was driven by the need for visibility into the pipeline and tests, and the company is now running 20-30 tests on every single pull request made against the project (46m10s).
  • The biggest value of transitioning to GitHub is making it easy for contributors to contribute to open-source projects, with features like a contributing.md file that describes how to contribute to Fern (46m55s).
  • A frustrating issue with the previous setup was that contributors had to log into Circle CI to access information, which was not accessible to them, highlighting the value of multiple tools in one platform (47m11s).
  • The key reason for switching to GitHub was for visibility, as it allows contributors to easily access information and contribute to the project (47m36s).
  • The transition from Circle CI to GitHub Actions was done gradually, with both systems running simultaneously for about two months before making the full-time switch (48m2s).
  • The transition was facilitated by using ChatGPT to convert Circle CI workflows to GitHub Actions' workflows.yaml file structure (48m11s).
  • The decision to build API documentation and CI/CD pipelines is driven by the fact that they go together well, like peanut butter and jelly, and are essential for a smooth development process (48m58s).

Contributing to Fern and Future Prospects

  • To contribute to Fern, one can look at the first CL issues, join the Slack community, and start the project on the GitHub profile (49m12s).
  • Exciting times are ahead for Fern, with incredible customers and new features in the pipeline, including a feature flagging website (49m58s).

Launch Darkly's Migration to Fern Docs

  • The developers tab is a crucial section, as seen in the example of Launch Darkly's developer documentation, which includes guides, SDK integrations, and API documentation (50m18s).
  • Launch Darkly initially built their own in-house developer documentation static site generator but found it too costly to maintain, leading them to migrate to Fern Docs (50m44s).
  • This migration is an exciting opportunity, as it shows a company re-evaluating their build decision and opting for a buy decision instead (51m18s).
  • A key lesson for founders is that just because they built something doesn't mean they need to maintain it, and if it's not achieving its goal, there may be a solution that can do it for them (51m31s).

Key Lessons for Founders and Fern's Success

  • The conversation highlights the importance of being open to change and reinvention, as well as starting with a problem that has a known need (52m23s).
  • Customer discovery may not always be reliable, as companies may not realize the potential of a solution, and looking at what successful companies have built internally can be a better indicator of a problem's validity (52m57s).
  • Fern's approach has led to companies like Amazon, Palantir, Stripe, and Twilio becoming their customers, and they hope to add GitHub to the list in the future (53m39s).

Advice for Founders and Co-founder Selection

  • If Danny could go back in time, he would tell his first-week self to focus on a problem with a known need, as this would have given him a head start (54m9s).
  • The most important decision as a founder is choosing a co-founder, as it is a long-term commitment similar to marriage (54m22s).
  • Co-founder matching, where individuals try to find a partner quickly, can be scary and is not always the best approach (54m50s).
  • An example of successful co-founder matching is the story of Dropbox, where the initial solo founder found a co-founder, Arash, after being advised to do so by Y Combinator (55m11s).
  • Arash is now a backer and angel investor in Fern, a company founded by Danny Sheridan and his co-founder, De (55m28s).
  • It is crucial to choose a co-founder with whom you have a social or academic connection, rather than someone you don't know (55m40s).
  • Danny Sheridan advises taking time to find the right co-founder, rather than rushing into a partnership (56m27s).
  • When searching for a co-founder, consider people you have worked with or studied with in the past, and try to narrow it down to a few names (56m36s).
  • The task of finding a co-founder is a critical one, and it's essential to sell them on the idea and convince them to join the venture (57m4s).

Joining the Fern Team and Final Remarks

  • Fern's contribution guidance is available for those who want to contribute, and checking out the good first issues is a good starting point to get involved with the team (58m1s).
  • The team is described as a super fun and dynamic team to work with, and joining their Slack community is encouraged (58m12s).
  • Fern's open-source product is used by major companies and can solve problems for those building now, eliminating the need to build in-house or reinvent the wheel (58m22s).
  • GitHub Startup Wednesdays is a program that provides benefits, including credits, but the most important aspect is the people involved, including the founders and those in charge of the program (58m51s).
  • The next episode of GitHub Startup Wednesdays will feature AB love. AI, one of the accelerator startups from the last cohort focused on AI (59m10s).
  • The program will be taking a two-week break before the next episode, and viewers are encouraged to build their startups on GitHub during the break (59m22s).

Overwhelmed by Endless Content?