For AI agents: a documentation index is available at the root level at /llms.txt and /llms-full.txt. Append /llms.txt to any URL for a page-level index, or .md for the markdown version of any page.
Sign inTry it free
DocsGuidesSDKsIntegrationsAPI docsTutorialsFlagship blog
DocsGuidesSDKsIntegrationsAPI docsTutorialsFlagship blog
  • Flagship blog
    • 52 Blog Posts, Claude, 3 Prompts, Under an Hour
    • Shipping from Oakland: An Observability Hackathon Recap
    • Day 12 | New Year, New Observability
    • Day 11 | What engineering teams really want from Observability
    • Day 10 | Why observability and feature flags go together like milk and cookies
    • Day 9 | The Three Ghosts Haunting Your AI This Holiday Season
    • Day 8 | Observable Multi-Modal Agentic Systems
    • Day 7 | SLOs that actually drive decisions
    • Day 6 | Stop cardinality from stealing your cloud budget
    • Day 5 | Using a Popular Tidying Method to Consolidate Your Observability Stack
    • Day 4 | Tracing the impact of feature flags in your Node.js app
    • Day 3 | Zero-Config Observability with OpenTelemetry
    • Day 2 | Why AI agents need three layers of observability
    • Day 1 | Observability Under the Tree: What Changed in 2025
    • 5 takeaways from my first PyCon JP conference
    • Dungeons & Downtimes: XP gained from our adventure
    • Reverse Proxy for custom domains
    • Adventures in dogfooding: Guarded Releases
    • A quick tool for npm package scanning
    • My DEF CON 33 experience
    • Make every launch a big deal
    • Fun with JS streams
    • Moonshots XXII: Hack to the Future recap
    • A tale of three rate limiters
    • My good friend Claude
    • My approach to React app architecture in 2025
    • Data isolation with ClickHouse row policies
    • Ingest and Visualization for OpenTelemetry Metrics
    • Alert Evaluations: Incremental Merges in ClickHouse
    • Optimizing ClickHouse: The Tactics That Worked for Us
    • Migrating from OpenSearch to ClickHouse
    • Revamping Privacy Mode: A Better Way to Obfuscate Sensitive Data
    • An open-source session replay benchmark
    • LLM-based Grouping of Errors
    • Building GitHub Enhanced Stacktraces
    • Vercel Edge Runtime Support
    • Finding Interesting Sessions with Markov Chains
    • Building Logging Integrations at LaunchDarkly
    • The Network Request Details Panel
    • Using Github as a Headless CMS
    • Your Source Maps Should Be Public
    • Supporting Outside Contributions at LaunchDarkly
    • Managing our design tokens at LaunchDarkly
    • Our Commitment to OpenTelemetry
    • The 5 Best Logging Libraries for Ruby
    • InfluxDB: Visualizing Millions of Customers' Metrics using a Time Series Database
    • 8 Tips to Help You Maximize Chrome DevTools
    • The Debugging Process and Techniques for Web Applications (Part 2/2)
    • 5 Best Node.js Logging Libraries
    • What are rage clicks and how to detect them
    • 5 Best Practices for Maintaining a Clean ReactJS App
    • Is Kafka the Key? The Evolution of LaunchDarkly's Ingest
    • What Is Full Stack Monitoring and How Does It Work?
    • The beauty of contact-first API design
    • What is Frontend Monitoring and What Tools Help You Do It?
    • 5 strategies to monitor the health of your web application
    • Configuring OpenSearch for a Write-Heavy Workload
    • Maximizing Our Machines: Worker Pools At LaunchDarkly
Sign inTry it free
LogoLogo
Flagship blog

Supporting Outside Contributions at LaunchDarkly

Was this page helpful?
Previous

Managing our design tokens at LaunchDarkly

Next
Built with

Published May 9, 2023

portrait of Vadim Korolik.

by Vadim Korolik

A few weeks ago, a passionate developer, Nils Gereke, wrote a new fully-featured Java SDK for LaunchDarkly. They built the CI necessary to automatically push packages to Maven. And yes, they even wrote documentation, a getting-started guide, and unit tests! In fact, since we open-sourced ~3 months ago, we’ve had 10 open-source developers independently ship features and bug-fixes.

Most open-source GitHub repositories want external contributors. But does open-sourcing your code-base guarantee developers will help you write code? We sure didn’t think so, but here the meaningful steps we took to make it easy for interested folks to contribute. Here’s what we did to make it easy for folks to get started:

  • We document everything publicly. GitHub issues became the source of truth for everything we work on internally. We started using labels like good-first-issue to identify good starter tickets and made it a habit to write thorough ticket descriptions. External contributors need more context to get started. We even create product proposals (we call these “RFC”s) publicly to get engagement from the community, and we open public GitHub discussions to get feedback from our customers.

  • We obsess over the developer experience. We’ve optimized our docker stack for the developer workflow, making sure the setup was smooth and key productivity-boosters like code hot-reloading and breakpoint debugging worked out of the box. Moreover, we’ve made self-hosting highlight a breeze by supporting different runtime environments with a pre-build cross-platform docker image. Plus open source contributors have a dedicated channel to ask about their setup and voice opinions regarding the DX.

  • We prioritize customer issues. Who better knows how to improve our product than the folks actively using it? We get a substantial number of ideas, enhancements, and issues reported to our open source GitHub daily, and we do our best to stay on top of them. Plus, the conversations often create an engaging platform for folks using LaunchDarkly to discuss their top features.

  • We built a supportive community. Our discord has been a great way to engage with contributors and users of the product alike. It has given open-source developers a way to message our engineers with questions and quickly resolve blockers. It has also unlocked a new stream of feedback and suggestions from our customers allowing us to further improve the product.

In the end, our open-source community is part of our team. By focusing on external contributors as much as we do on our internal engineering team, we see ourselves building a powerful and diverse team that can autonomously improve LaunchDarkly for all.