How to Encourage Community Contributions

Ming and I started ParadeDB a year ago. ParadeDB is an open-source database project that adds BM25 full-text search and fast analytics support to Postgres. We witnessed Postgres users be frustrated by Elastic's limitations (denormalization, lack of JOINs, operational challenges) and set to offer a SQL-native alternative.

ParadeDB is our first serious open-source project. We adopted this approach to facilitate developer adoption and shorten the feedback cycle. We now see regular community contributions, an unexpected but welcome side effect of building open-source.

I have spent a long time reflecting on why the community has welcomed us so openly and why so many intelligent, hardworking people have carved time out of their busy schedules to submit contributions to our project. I'm not an expert, but here are a few ideas I have honed for building momentum behind an open-source project.

  • Be genuine. We spent our first year focused on helping people rather than selling them something. This made our early adopters feel welcomed and significantly increased feedback and adoption.
  • Work hard. People respect hard work, even when it is clear the job is incomplete. I was surprised to see individual users and design partners double down on their support after facing bugs because of how quickly we acted on their feedback.
  • Be transparent. Closed-source enterprise software companies often promise features that don't exist yet. It's hard to do this in the open source because users can quickly read your code and tell whether your promises are empty. We have found that the more transparent we are about the project's state, the more our community is supportive and willing to help build the missing pieces.
  • Be reachable. We try to respond to users within 24 hours and follow ParadeDB-related keywords across popular social media platforms. Our users feel comfortable communicating with us and are often surprised to see me engage with their content directly.
  • Be intellectually honest. From day one, we've made it clear that our goal is to build a sustainable open-source business on top of our project. We tried to be thoughtful and intentional in decisions like licensing and were pleasantly surprised by the community's reaction.
  • Focus on quality over quantity when writing content. Last year, we wrote six blog posts. We found that only writing when we had something interesting to share led to higher awareness of our project than a high number of less exciting blog posts. We spent more time on each blog post but probably still invested less time than if we had gone for a higher number of posts, which is a nice side effect.
  • Focus on providing value, not on promoting your project. We follow ParadeDB-related keywords and engage with users on related content. When we do, we try to provide value by answering questions and offering insights gained through our work. This leads to more interesting conversations that incentivize readers to look us up and discover ParadeDB organically.
  • Work on something people already like. The love for Postgres is real, and by working to make Postgres better, we inherit this love. People root for our success, which motivates our team and encourages others to join the movement.
  • Position yourself against something people know and dislike. Elasticsearch is a very popular technology, which makes its drawbacks well known. Its popularity helps us connect with a large audience familiar with the pain points we are solving. The enemy of my enemy is my ally, after all.
  • Work on something you are passionate about. Passion is contagious. Every day, we wake up excited to work on ParadeDB and eager to engage with our community, who can feel our excitement. This is also one of the primary criteria we screen for when hiring.

Thanks to Ming Ying and Eric Ridge for reading drafts of this.