liorgrossman

Not yet.

We do hope to integrate with Open Collective and others to fetch some of that data!

Yeah, it is pretty darn complicated!

A couple of things that helped us with the rate limits are: * Limiting most of our graphs/reporting to the past 3 years (some repos are pretty old) * Fetching the data incrementally - namely, the first fetch is kinda of large, but then we're only trying to get the minimal set of changes/detla to a repo on a regular basis!

That sounds awesome, I can't wait to see the product when it goes live!

Thank you!

Thank you! We actually have a waiting list for those: https://docs.google.com/forms/d/e/1FAIpQLScexiehdwDWJwxZJym8...

Some use cases where package maintainers might be willing to pay to promote their packages: * API companies that want to promote their product, mainly newcomers to the market that look for developers' mindshare, but probably incumbents as well. * DB and other infrastructure companies that have packages (drivers, libraries, tooling) * SaaS companies who's users are developers (e.g. monitoring, logging, analytics) * Some indie developers who are willing to pay a few bucks to get those first thousand users to their package and get it off the ground. * Software development firms/agencies that build packages as a means of showcasing their expertise, use the package as a way to build reputation and get more clients

That's a really interesting thought, we've never thought of this direction! Are there any successful products/companies with such business model (providing testing and certificates for money)

Thank you, we all share the same pain with package search.

The categories curation in Openbase includes a category, but also a framework. So as you mentioned, under Table libraries, you could have React, Vue, Svelte libraries etc.

We currently filter those by framework, but unfortunately, we didn't have the time to fully implement this page prior to the launch.

What should be in this page is a dropdown where you can choose from 10 different frameworks, and see the results for that specific framework. That dropdown, along with the URL routing to support it, is still missing from the product. It's one of the most important things on our roadmap, so expect to see it on Openbase soon.

Unfortunately, there's no way to 100% ensure all packages are included inside a category since the curation is manual, but I would say we do base it on extensive Google/npm/GitHub search. In the future, we want to involve the community in the curation process, so anyone can suggest new packages for a category or categories to a package. Not a simple thing to implement, but we chose this challenge since we do feel that categorization can provide a lot of value.

Interesting, that is something that we had in mind in the past. I know there are few good websites doing that, starting with simple bounties like IssueHunt and ending with more complex models like Tidelift. I'm not sure how well those work, honestly.

One similar thing we were thinking of is giving maintainers the platform to easily provide paid support if they want to. Not sure about that one either, although I know some companies/people make money from providing support for OSS.

You know what they say? It's not a startup until you buy the domain name ;-)

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.

Thank you for sharing this!

As you mentioned, we're focused on the discovery part, and package insights is a part of that, but so are reviews, ratings, search, and categorization.

Your tool looks like a great solution for software teams to get insights into their code and dev processes, this also connects with the "developer velocity" trend I've heard several times in recent years.

Looks like quite a lot of work too, kudos!

Is it in production with some customers?

In terms of bizmodel - we're thinking about paid promotion of packages - allowing maintainers (companies and individuals) to promote their packages.

We want to limit it to a single clearly-marked promoted package for each category. Obviously, we would just surface the promoted package, but the package reviews, insights, and metrics are obviously untouched.

Obviously, users would be happy if GitHub included some of those functionalities inside the repos. However, I don't think GitHub could simply put user reviews on all repos (technically they could, but business-wise that would not be a smart decision). So even if they were to do that, and user reviews were an opt-in feature in GitHub, then you'd have reviews enabled for some packages and not for others, which is suboptimal.

We get this feedback a lot actually - and we do plan to integrating bundle size (e.g. gzipped/uncompressed) into the product soon.

In terms of business model - we're actually thinking about paid promotion of packages: allowing maintainers (companies and individuals) to promote their packages, we found there's a big need for that. We want to limit it to a single (clearly marked) promoted package for each category. Obviously, we would just surface the promoted package, but the package reviews, insights, and metrics are obviously untouched.

Any thoughts on that approach?

I feel you.

I heard from several maintainers about this phenomena, where at first all you want is your package is to be popular and have many users, but after a while you notice having more users is becoming a burden, with so many requests, issues, and opinions.

But I can see what you mean. We're still small enough, but I would assume if Openbase becomes a success we take on a lot of responsibility - in terms of making sure maintainers rewarded (not necessarily monetarily) and not punished for their good work.

Yeah, I assume the vast majority of paying maintainers would be SaaS companies (for services like monitoring or logging), API companies, infrastructure companies (DBs, etc.)

I do think the vast majority of these companies already have packages, since they need developers to integrate with their services.

Oh wow, great feedback.

We do have a metric like median time to resolve issue - and we even display it on a chart over time.

Sentiment analysis (natural language or emojis) could be really interesting in terms of assessing the issues, we probably don't have the resources to pull this off right now but this would be amazing.

and yeah, we should be careful not to incentivize user behavior that rewards criticizing maintainers as some kind of a leverage.

Yep. We're considering Python, Go, Java and few others.

We have a waiting list here! (also there's link in the homapge) https://docs.google.com/forms/d/e/1FAIpQLScexiehdwDWJwxZJym8...

You got it right!

Currently the only way to create an account is through GitHub login (we're going to add more options in the future). That means in order to write a review you have to log in with GitHub.

Behind the scenes, text reviews do not show immediately, we go over them and approve them manually, to verify there's not bad behavior, spam, offensive content, etc.

We plan on approving each text review ourselves manually until we're stretched too thin and this plan doesn't scale anymore.

Thanks for the kind words We built it to solve our own problem (spending so much time trying to find the right package). Happy to hear it's useful for others like yourself!

Thank you! We do plan to offer an API in the future - there are tonnes of cool things that can be built around this data. We were even approached by a couple of companies that were willing to pay for such API! (that was cool) However, we're currently a really small team and it's hard enough wrapping our head around everything we want to do with the website, so we decided the API is something we can pursue as we grow the team.

That's a great question, I agree this might become a problem down the line, when bad players might try to pressurize package maintainers into fixing problems.

We haven't encountered this problem yet, and believe most developers are decent enough to honestly rate a package based on their experience, as opposed to using it as a leverage.

Few things we're thinking about:

* Allowing maintainers to flag such reviews (for our review)

* Allow users to upvote/downvote reviews, and flag bad behavior (spam, extortion) to stir away bad players.

* Allowing maintainers to publicly to reviews

* Gathering enough data (about review and other previous user reviews) to conceal "bad" or non-useful reviews, in a similar manner to other platforms.

What do you think? Do you have any other suggestions?

It is a lot of work.

In terms of making money - we're thinking about paid promotion of packages: allowing maintainers (companies and individuals) to promote their packages, we found there's a big need for that. We want to limit it to a single (clearly marked) promoted package for each category. Obviously, we would just surface the promoted package, but the package reviews, insights, and metrics are obviously untouched.

Wow, nice collection of themes! I could have really used something like that a few months ago. I developed a Gatsby site and literally spent an hour searching for a good-looking theme.