TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Launch HN: Openbase (YC S20) – reviews and insights for open-source packages

148 点作者 liorgrossman将近 5 年前
Hi everyone! I&#x27;m Lior, one of the makers of Openbase (<a href="https:&#x2F;&#x2F;openbase.io" rel="nofollow">https:&#x2F;&#x2F;openbase.io</a>). We help developers choose the right JS package for any task - through user reviews and insights about packages&#x27; popularity, reliability, activity and more.<p>I have started Openbase out of my own frustration as a developer: there are 1.3 million JavaScript packages out there, and I found myself spending an increasing amount of time researching and evaluating packages every time I wanted to accomplish a task - displaying an autocomplete, sending an HTTP request, extracting significant keywords from an page, etc. Each time I would make that research, I spent hours reading different blogposts comparing those packages, going over PRs and commit messages to see how active the development or maintainers are, and trying to cross-reference data from npm and GitHub to get to a decision.<p>We started by gathering data from npm and GitHub - from versions and dependencies, to commits, pull requests, maintainers and tried to figure out what insights we could surface that could help us (and fellow developers) choose the right package. We ended up adding automated insights like star count over time, commit frequency, time between major&#x2F;minor versions, average time to resolve issues and PRs, percent of commits by the community, dependency insights, and more. Here&#x27;s what the insights page looks like: <a href="https:&#x2F;&#x2F;openbase.io&#x2F;js&#x2F;react" rel="nofollow">https:&#x2F;&#x2F;openbase.io&#x2F;js&#x2F;react</a><p>We decided not to stop there, and allow our users to discover the best packages for performing each task and compare them side-by-side. We&#x27;ve already manually curated several hundreds categories, such as CSS frameworks, OAuth packages, and HTTP request libraries: <a href="https:&#x2F;&#x2F;openbase.io&#x2F;packages&#x2F;best-javascript-css-framework-libraries" rel="nofollow">https:&#x2F;&#x2F;openbase.io&#x2F;packages&#x2F;best-javascript-css-framework-l...</a> On the long term, we want to build tools that will allow the community to curate and maintain categories, and get to thousands of categories for any imaginable task.<p>Lastly, over the past couple of weeks we decided to try something more ambitious - we want to let developers rate and review open-source packages. While data and metrics are great, we found ourselves often consulting with friends and colleagues about which package to use. We think reviews could reveal a lot of insights that cannot be deduced by looking at metrics alone. To throw in even more fun to the mix, we added badges like &quot;Great documentation&quot;, &quot;Performant&quot;, and &quot;Hard to use&quot; (check it out: <a href="https:&#x2F;&#x2F;openbase.io&#x2F;js&#x2F;vue" rel="nofollow">https:&#x2F;&#x2F;openbase.io&#x2F;js&#x2F;vue</a>), and are looking for ideas for more badges.<p>We found that many maintainers want to promote their packages, and unfortunately, there aren&#x27;t good ways of doing so today. This is a problem for new package maintainers who are having a hard time getting those first thousand users, an API&#x2F;SaaS company that wants to earn developers&#x27; mindshare, or a software firm that wants to showcase their expertise. We&#x27;ve started by allowing package maintainers to claim their package page, and giving them the tools to promote it for free. In the future, we want to allow for paid promotion of packages - limiting it to a single, clearly-marked promoted package for each category. We would just surface the promoted package, but the package ratings, reviews, insights, and metrics are obviously untouched. We believe this kind of balanced approach could make Openbase a sustainable company, while not impairing the user experience.<p>In the good ol&#x27; 90s, when I made my first steps with JavaScript, and it was all about small scripts to make web pages a bit more interactive. I can&#x27;t believe two decades later, the JavaScript ecosystem has gotten so huge and complicated, that we&#x27;ve actually built a startup to help you navigate this mess. Strange world, isn&#x27;t it?<p>We would really love to hear your feedback about Openbase, and in particular about the reviews feature. How would you go about making the reviews a force for good, and making sure reviews are helpful for other developers and the community at large?

25 条评论

koolba将近 5 年前
What’s the business model to get paid for something like this? Alternatively phrased, how is this a sustainable business?<p>And how do you beat Microsoft from melding in this functionality into GitHub &#x2F; NPM? The friction would so much lower (existing GitHub account) and they can place the information directly on the project pages.
评论 #23836178 未加载
johnfn将近 5 年前
On one hand, this is fantastic and desperately needed. I&#x27;ve wanted something similar for years.<p>On the other hand, I&#x27;ve been an open-source developer (one of my projects has 7.5k stars on GitHub) and the constant stream of negativity towards that the work I put hundreds of hours into for free was pretty psychologically draining, to say the least. And it&#x27;s actually a pretty well-liked project! By making such a service you take on a lot of responsibility here.
评论 #23836069 未加载
pragmaticivan将近 5 年前
How are you going to prevent nasty people thinking they have the right to hunt down open-source creators who work for free and should have no pressure to get things done? Feels like such a platform can also cause stress with people trying to rate a package when they take no time to actually help with commits into the package.
评论 #23834232 未加载
jerrygoyal将近 5 年前
I&#x27;ve been doing js development for years and feel the same pain when I need to look for the npm package with the right balance of functionalities,size,active development,popularity etc. A dedicated site for package recommendation would definitely save lots of time, currently, I use npmtrends.com for this. I quickly checked for packages on openbase.io for rendering table and found out there were packages only for vuejs. why to exclude react packages? I also understand it&#x27;s an mvp but Package results sorting should be there. Reviews would definitely help but I&#x27;d also prefer to see likes&#x2F;upvotes on those reviews to get extra validation.<p>On a side note how are you ensuring that all popular packages should be included in your database? Otherwise it wouldn&#x27;t make sense if user needs to crosscheck on google&#x2F;npm&#x2F;github like in this case of rendering table.<p>I&#x27;ll be regularly using openbase for package discovery. Wish you all the best!
评论 #23836788 未加载
rikroots将近 5 年前
Thank you for creating this site - it looks like an excellent piece of work. I hope you find a way to make some money from the work, enough at least to pay the hosting bills.<p>A couple of questions:<p>1. I found a way to add a tutorial link to my package&#x27;s page, but the wider documentation seems to be limited to whatever is put in the README.md file. Is there a way to add links to additional documentation?<p>2. You mention elsewhere in the thread possibly adding download sizes to the package page. This worries me a little because NPM appears to list the full size of the entire repository (which for my library is 44.5MB - the repository includes a lot of demos, assets for those demos, inline documentation, etc). Whereas the &#x27;real&#x27; size of the minified file - the one which would be served to websites - is only 302KB (78KB zipped). If you do include download sizes in a future version, can I ask that you also include a way for maintainers to flag misleading information?<p>[Editing to ask] 3. How can I get my package to show up in the search results, when people search for &#x27;canvas&#x27;?
评论 #23864763 未加载
ldd将近 5 年前
Does this include typescript projects? i couldn&#x27;t find my own.[0]<p>Also, I can see my two most popular packages ( 40 stars[1] and 14[2] respectively), and I&#x27;ve realized that not updating them frequently probably hurts.<p>The thing is, what about bots like dependabot? I have one or two other packages that auto update and close issues quickly because they have some bots helping out, and I was wondering if you took that into account.<p>I am also sad that things that I worry about, like testing, and bundle size are nowhere to be found.<p>But overall, great idea. Keep at it!<p>[0]:<a href="https:&#x2F;&#x2F;github.com&#x2F;ldd&#x2F;vscode-jq&#x2F;" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;ldd&#x2F;vscode-jq&#x2F;</a><p>[1]:<a href="https:&#x2F;&#x2F;openbase.io&#x2F;js&#x2F;gatsby-source-github-api" rel="nofollow">https:&#x2F;&#x2F;openbase.io&#x2F;js&#x2F;gatsby-source-github-api</a><p>[2]:<a href="https:&#x2F;&#x2F;openbase.io&#x2F;js&#x2F;react-tech-tree" rel="nofollow">https:&#x2F;&#x2F;openbase.io&#x2F;js&#x2F;react-tech-tree</a>
评论 #23837562 未加载
rhacker将近 5 年前
Another interesting metric to try to capture would be issue resolution. A lot of time you might have a very decisive issue in Github where the developers basically piss off a lot of their users. I don&#x27;t think that&#x27;s generally a good metric to promote as a top level metric obviously, but it would be interesting way to slice and dice projects.<p>But that analysis could look for thumbs up or fireworks or other Happy reaction emoji vs negative feedback emoji tied to the replies of people on the team.<p>Yes, this goes back to criticizing open source maintainers for not doing what everyone wants - so perhaps that kind of metric would only be enabled on sponsor backed repos.
评论 #23835979 未加载
sdesol将近 5 年前
This is cool and I appreciate software development insights is getting some love. Full disclosure, I wouldn&#x27;t say I&#x27;m working on the same thing, but we definitely have some overlap, when it comes to software development insights, which is gaining steam.<p>Your dashboard gave me some interesting food for thought, so I&#x27;ll do the same and share with you, some of the things that I&#x27;m working on, that you are free to incorporate into openbase.<p><a href="https:&#x2F;&#x2F;imgur.com&#x2F;Y06Tk3f" rel="nofollow">https:&#x2F;&#x2F;imgur.com&#x2F;Y06Tk3f</a><p><a href="https:&#x2F;&#x2F;imgur.com&#x2F;Yjk2dzR" rel="nofollow">https:&#x2F;&#x2F;imgur.com&#x2F;Yjk2dzR</a><p><a href="https:&#x2F;&#x2F;imgur.com&#x2F;RJw4ygS" rel="nofollow">https:&#x2F;&#x2F;imgur.com&#x2F;RJw4ygS</a><p><a href="https:&#x2F;&#x2F;imgur.com&#x2F;xXi9EMd" rel="nofollow">https:&#x2F;&#x2F;imgur.com&#x2F;xXi9EMd</a><p><a href="https:&#x2F;&#x2F;imgur.com&#x2F;nROCA0O" rel="nofollow">https:&#x2F;&#x2F;imgur.com&#x2F;nROCA0O</a><p><a href="https:&#x2F;&#x2F;imgur.com&#x2F;xhb2haD" rel="nofollow">https:&#x2F;&#x2F;imgur.com&#x2F;xhb2haD</a><p><a href="https:&#x2F;&#x2F;imgur.com&#x2F;sZ2YpIM" rel="nofollow">https:&#x2F;&#x2F;imgur.com&#x2F;sZ2YpIM</a><p><a href="https:&#x2F;&#x2F;imgur.com&#x2F;HVSNhS0" rel="nofollow">https:&#x2F;&#x2F;imgur.com&#x2F;HVSNhS0</a><p><a href="https:&#x2F;&#x2F;imgur.com&#x2F;TnInleD" rel="nofollow">https:&#x2F;&#x2F;imgur.com&#x2F;TnInleD</a><p>My focus is not on the discovery part, which you guys are working on, but rather, I&#x27;m more focused on providing &quot;business intelligence&quot; for the software development lifecycle.<p>I do agree with you that code metrics can only tell you so much, as it&#x27;s not really meant for discovery. Code insights might provide things like stability, investment, complexity, etc., but like you said, you can&#x27;t tell from code insights, if the code is easy to use or not. Discovery is a serious problem and GitHub has certainty not solved this problem yet, so what you guys are working on, is a problem worth solving in my opinion.
评论 #23836272 未加载
eatonphil将近 5 年前
Immediately went looking for how to be a reviewer or who reviewers currently are (vetted), but didn&#x27;t find anything? Clicking into a package I&#x27;m invited to leave a review where I see it&#x27;s tied solely to my GitHub login. Not bad, but hard to see how the reviews are approved or curated. The centralization could be nicer than having to read a bunch of blog posts to get the gist but I&#x27;d rather defer to a proven community (like Debian&#x27;s package maintainers) for guidance on JS packages. That&#x27;s not a thing today, so maybe this project is a good first step.
评论 #23834863 未加载
fuzzythinker将近 5 年前
How are libraries added to a category? Manual? Eg. <a href="https:&#x2F;&#x2F;openbase.io&#x2F;packages&#x2F;top-javascript-frontend-framework-libraries" rel="nofollow">https:&#x2F;&#x2F;openbase.io&#x2F;packages&#x2F;top-javascript-frontend-framewo...</a> seems very lacking.<p>Side note, selecting frontend frameworks from the sidebar gives the same list but the URL stays <a href="https:&#x2F;&#x2F;openbase.io&#x2F;categories" rel="nofollow">https:&#x2F;&#x2F;openbase.io&#x2F;categories</a> - URL should update.
评论 #23864676 未加载
bartmika将近 5 年前
Beautiful and wonderful, thank you for building and sharing this! I use these sort of websites all the time so this is very useful for me.<p>Congrats on the launch!
评论 #23834562 未加载
switz将近 5 年前
I would really love if this displayed the bundle size of each package (a la bundlephobia[0]).<p>I&#x27;m not quite sure I understand how or why this is a business, but there certainly is some base level of utility value. I have a feeling this will ultimately end up encapsulating a job board.<p>[0] <a href="https:&#x2F;&#x2F;bundlephobia.com" rel="nofollow">https:&#x2F;&#x2F;bundlephobia.com</a>
评论 #23836098 未加载
neximo64将近 5 年前
Nice, now we can review someone&#x27;s open source contributions they usually worked for free on.
评论 #23838049 未加载
评论 #23838039 未加载
patrickaljord将近 5 年前
Do you plan to provide an API to build cool stuff around this? Congrats on the launch.
评论 #23834542 未加载
aflag将近 5 年前
It&#x27;d be interesting if there was some way to measure user satisfaction per release. It would be nice to know which versions are working well for people and which ones are breaking things.
评论 #23838591 未加载
ishcheklein将近 5 年前
Do you have a plan to expand to other projects, not related to JS?
评论 #23835137 未加载
jacques_chester将近 5 年前
This looks like a lot of work. How will Openbase make money?
评论 #23833718 未加载
barefootford将近 5 年前
Very cool idea - Surprised there isn&#x27;t already someone doing this. Annual surveys are interesting but a bit of a slow feedback loop.
评论 #23839413 未加载
minerjoe将近 5 年前
I hate to be that guy, but should I switch to a browser with javascript just to see the landing page?
评论 #23841978 未加载
gramakri将近 5 年前
Looks great. Can you add testing coverage as one of the metrics?
评论 #23838566 未加载
DanielShir将近 5 年前
Kudos for Lior and the team, great product!
评论 #23849548 未加载
yadco将近 5 年前
Cool. Does it include who backs a project?
评论 #23837496 未加载
est将近 5 年前
Do you provide source code auditing?
评论 #23849570 未加载
ralfhn将近 5 年前
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)<p>Here are some random ideas I&#x27;ve been thinking about, maybe some of it would be useful to you:<p>Possible monetization strategies:<p>You mentioned &quot;paid promotion of packages&quot; 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:<p>- 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.<p>- Commenting&#x2F;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&#x27;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.<p>- 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.<p>- 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&#x27;m not entirely sure how this would look like, but I think it&#x27;s worth exploring.<p>Challenges:<p>- Github has been doing an excellent job recently. Building all this out is way simpler for them since they own the source data. Don&#x27;t be surprised if they take you out of business by implementing similar features. Have a backup plan for when (not if) this happens.<p>- 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&#x27;s OAuth tokens, plan on having a robust security practice, because it will be scrutinized.<p>- 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&#x2F;vet all transitive dependencies.<p>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.
评论 #23836533 未加载
nagarc将近 5 年前
Good Initiative
评论 #23849541 未加载