Sixth Month Building an Open Source Startup

Sixth month metrics for Watermelon

• North Star Metric
• Monthly Active Users 169 ⬆️ (prev 160)
•  
• Engagement
• Number of people who activated Watermelon: 216 ⬆️ (prev 211)
• Conversion from opened to active user: 78% ⬆️(prev 76%)
• People who used us 12+ days this month: 54 ⬇️ (prev 58)
•  
• Acquisition
• New Users 101 ⬆️ (prev 77)
• New GH Stars 7 ⬇️ (prev 10)
•  
• Accumulated
• Accumulated total unique users: 680 (prev 579)
• Accumulated total downloads: 3900 (prev 3200)
• Accumulated total GitHub stars: 284 (prev 277)
• Accumulated total contributors: 21 (prev 21)

‍

Last month we talked to our users and concluded that the best next integration to build was one with ticketing systems. Seriously, that was pretty much it. We concluded that with the very same science of running git blame on the background to bring to your IDE the most relevant parts of the git history for a given line or block of code, we can bring to you the most relevant Jira ticket. 

‍

The image below (best meme template ever! lol) explains our train of thought very well. 

Just one note here. We like “more juvenile” ticketing systems such as Linear, Shortcut and Notion’s Kanban board better. But in reality, our best customers are gonna be bigger organizations that have been using Jira for years, so we’re starting there. Once we nail this integration, we will definitely bring integrations with newer ticketing systems to our VS Code extension. 

‍

Heads down building our Jira Integration

This is our mission right now. 

‍

Every new integration means a whole new universe to us. I like to compare it to when startups doing something operational “open up a new country”. Learning how to use a new Rest API is just part of the job. We have to make it fit into the developer experience. We have to refactor some code. We have to think about how to become a common auth provider for all our integrations.

‍

We also gotta test different stuff with what Atlassian provides us, to be sure that we’re gonna release something plausible. Which brings us to the next point. 

‍

Thinking about better heuristics

How should the algorithm to bring the most relevant Jira ticket work at all? 

‍

We have the commit hashes obtained from running git blame to start with. What can we do with that? Should we do word matching? If so, should it be on all text on the ticket, or just a single section like the title? What about filtering by ticket status? Do people want to see what’s closed and that’s it? Or what’s opened? Or both?

At the moment, we’ve concluded that we can do a lot with the title of the most relevant PR obtained from a mixture of git blame and hitting an Octokit endpoint. Which brings a new set of questions: What’s the best heuristic for sorting PRs by relevance? Is it the number of comments as we’re doing right now? The number of lines changed? Who created the PR? Something else? 

‍

Talking to our users gives us a better sense of product. 

‍

Talking to our users to understand our best use case

We believe in doubling down on what we’re being good at, even if it’s just for a small subset of people. 

‍

Right now we’re helping engineering teams understand what PR was the most relevant one for a breaking change. We’re helping people get pointed to the right PR needed for them to unlock their next change. 

‍

We wanna keep getting better at retrieving the most relevant parts of git history for our users. While at the same time we start indexing more sources of information. 

‍

If you have any suggestions for us, please let us know! You can join our Discord to do so. 

‍

What’s next

• Releasing the Jira integration to become a post-revenue company is our most important goal right now. All we’re gonna be doing is building such and talking to users to make sure we build the correct variation of it. 

‍