In 2022, we started a genre-defining project that we hoped would transform how people maintain their code quality. We figured we should facilitate running custom and community analyzers/linters on DeepSource alongside our core analyzers.

Macro was the internal codename for custom analyzers. The initial goal was to allow users to write their own analyzers, and we’d provide the tools to author and host them, similar to the way npm hosts community node packages ⎯ an NPM for static analyzers, so to speak. The first pass at this was just a place on DeepSource to host their analyzers. The user would define a namespace in their team, and test and upload their analyzers using the DeepSource CLI.

Research

We knew that we needed to support more Analyzers than the existing set of DeepSource’s core defaults. We had prospective customers always ask us for more Analyzers that would help them maintain code quality on their codebases. Requests for a Dart Analyzer or a Cloudformation Analyzer were extremely frequent and a lot of customers were resistant to make the switch the DeepSource because it affected their ability to scan these codebases and they did not want to maintain multiple tools.

Target user ⎯ Engineering ICs and managers

Ideal for those who want to take their existing linter rules to DeepSource without sacrificing the ease of use that DeepSource brings to the table. Additionally, making new custom analyzers was a tedious job.

Business goal ⎯ The initial goal was to grow the user base in enterprise organisations. Over time, this evolved into a product offering for all users that directly boosted signups and revenue.

User assumption ⎯ We hypothesised that when the user’s own tools come onboard in their code quality tool, the reluctance to set up a whole new tool would significantly decrease, allowing for better adoption in bigger organizations.

User research ⎯ I conducted internal interviews to identify key use cases for this feature. I found team members who would not want to setup a new custom analyzer and themselves wanted ways to bring their existing linters into the DeepSource fold. The same pattern came across when we asked the same set of questions to our broader users and customers by engaging with our extended community.

User stories

• As an engineer, I’d want to bring my familiar linters (along with ignored issues and other preferences) with me to my workspace instead of solely relying on DeepSource analyzers (regardless of how superior they are).
• As an engineer in a security/infra team, I would want to reduce the number of moving parts and leverage existing tools in all workflows instead of having to set up everything separately and then constantly auditing this extra tool in the workflows.
• As an engineering lead, I would want my team to use more of predictable, open-source tools instead of proprietary tooling for bleeding-edge, and security issues.