| This is neat. Vetting dependencies is an essential yet understated task, and there are simply no existent tools on the market. I started creating a similar tool on the side (by starting I mean I just bought a domain name ;-) depvet.io) Here are some random ideas I've been thinking about, maybe some of it would be useful to you: Possible monetization strategies: You mentioned "paid promotion of packages" as a way to monetize, what I had in mind is a bit different: on-premise installation. You provide tools to scan an entire Github org then build your UI based on that. Besides vetting, there are plenty of features you could add: - Blocklists: it is common for companies to have a list of packages you cannot use. It could be based on a number of criteria like authors, licenses, collaborators, etc. We have one in Confluence and I always forget to look it up. - Commenting/Rating: When looking at a dependency, I usually do a Github search to find other teams that use it and ask them about their experience. Sometimes there are specific caveats that you can't find online; sometimes, we already have a fork that we need to use instead. A tool where I can see all projects using a particular package, internal comments, rating, and maybe even integration code samples would certainly be welcome. - Security vulnerabilities: While there are plenty of startups in this area, most of them appeal to the security org and not the engineers. If you integrate the security component into the vetting process, I think you can touch a bigger audience. - Fork maintenance: forks are a pain to maintain and keep up to date. Sometimes you forget why you had a fork in the first place. I'm not entirely sure how this would look like, but I think it's worth exploring. Challenges: - Github has been doing an excellent job recently. Building all this out is way simpler for them since they own the source data. Don't be surprised if they take you out of business by implementing similar features. Have a backup plan for when (not if) this happens. - Github API rate limits: 5000 requests per hour is not much, it may be enough for one language, but you eventually have to add more. If you were thinking of using the user's OAuth tokens, plan on having a robust security practice, because it will be scrutinized. - The single most important metric, in my opinion, is not present in your tool: The total number of dependencies. The flaws in direct dependencies are just as bad as flaws in indirect ones, and while I can quickly look at the package.json to determine the first level, there is no simple way to see/vet all transitive dependencies. I wish you the best of luck and I think you have something here, but I suggest spending some time on your monetization strategy before you go any further. |
Thanks for sharing your thoughts!
We did give the enterprise route a consideration - after all we have all those insights for all these dependencies, that could be really useful in the context of an organization. However, we decided not to pursue it since it seems this market is a bit crowded, with many security/license/dependency monitoring and management tools for the Enterprise. I agree we could come up with something unique (e.g. integrating it with insights and ratings as your said), this is probably not the first path we'd pursue in terms of monetization, there are other monetization models that I think might be easier to develop & test.
100% agree on GitHub doing an excellent job and being innovative and nimble even as part of a big company (Microsoft). While I think it would be fairly simple for GitHub to introduce more metrics and insights to repos, I think building a reviews/recommendation website requires a different mindset, focus, and essentially. Also, it doesn't necessarily fits in with their business model (hosting of repos and providing services around that).
Great point about the dependencies! We currently only display direct dependencies, but when assessing the health of a library, it's important to assess all transitive dependencies too, we've somehow neglected that, but will incorporate that into our roadmap.
Thanks for all the ideas! We're a small startup, and we're still putting a lot of our hypotheses (re product and business) to tests. Let's see what the future holds for Openbase.