liorgrossman

10 ms·

1. 61.▲
   by liorgrossman 6y ago

   Thanks!
2. 62.▲
   by liorgrossman 6y ago

   Thank you!
3. 63.▲
   by liorgrossman 6y ago

   Yeah, preventing fake reviews is a tough challenge faced by much larger companies, like Amazon, Google and Facebook. I don't think anyone has been able to 100% prevent those, so it's still work in progress. I guess once we cannot
4. 64.▲
   by liorgrossman 6y ago

   Thank you! Annual surveys are very interesting to read to see the macro trends, but as you mentioned they can't keep up with the pace of the JS ecosystem. Furthermore, they cover the major categories (e.g. big frameworks or tooling),
5. 65.▲
   by liorgrossman 6y ago

   Hehe :) A few other people asked about testing, too, but it's going to be challenging to build something that works reliably at scale with different codebases and testing frameworks. But I think I got the idea of what you're looki
6. 66.▲
   by liorgrossman 6y ago

   I didn't know that (and BTW Ruby-Toolbox is a great source of inspiration) I think the challenge with that is that there's no standardization of categories. Both GitHub and npm have the concept of "topics/keywords"
7. 67.▲
   by liorgrossman 6y ago

   We were actually toying with the idea of showing vertical lines for releases on the various charts. So for example: # of open issues over time, and you can see if it correlates with a major release. Identifying user satisfaction automatical
8. 68.▲
   by liorgrossman 6y ago

   Thank you. You mean a percentage (77%), like the one you usually see on a README badge?
9. 69.▲
   by liorgrossman 6y ago

   Awesome, I'm honestly not deeply familiar with most of those industries (let alone maybe credit rating agencies), but this is definitely a model that we need to explore. Thanks!
10. 70.▲
    by liorgrossman 6y ago

    I feel you, as I have tremendous respect and appreciation to open-source maintainers. Nevertheless, I think most developers already "review", critique, and share their opinion of open-source libraries loud and proud. They just don
11. 71.▲
    by liorgrossman 6y ago

    Thanks! We currently only cover npm packages (not all GitHub repos), does vscode-jq have an npm package? We currently don't have any special handling for bots, but this is on the pipeline. Same goes for consolidating contributors (some
12. 72.▲
    by liorgrossman 6y ago

    Not yet. We do hope to integrate with Open Collective and others to fetch some of that data!
13. 73.▲
    by liorgrossman 6y ago

    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 fi
14. 74.▲
    by liorgrossman 6y ago

    Thank you!
15. 75.▲
    by liorgrossman 6y ago

    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
16. 76.▲
    by liorgrossman 6y ago

    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)
17. 77.▲
    by liorgrossman 6y ago

    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 curren
18. 78.▲
    by liorgrossman 6y ago

    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
19. 79.▲
    by liorgrossman 6y ago

    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 cou
20. 80.▲
    by liorgrossman 6y ago

    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 team
21. 81.▲
    by liorgrossman 6y ago

    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. Obv
22. 82.▲
    by liorgrossman 6y ago

    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 mai
23. 83.▲
    by liorgrossman 6y ago

    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,
24. 84.▲
    by liorgrossman 6y ago

    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 packa
25. 85.▲
    by liorgrossman 6y ago

    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 pr
26. 86.▲
    by liorgrossman 6y ago

    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...
27. 87.▲
    by liorgrossman 6y ago

    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 review
28. 88.▲
    by liorgrossman 6y ago

    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!
29. 89.▲
    by liorgrossman 6y ago

    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&#x
30. 90.▲
    by liorgrossman 6y ago

    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 ar