Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

71–80 of 88 posts

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

#72

Post by rikroots »

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.

A couple of questions:

1. I found a way to add a tutorial link to my package'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?

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 'real' 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?

[Editing to ask] 3. How can I get my package to show up in the search results, when people search for 'canvas'?

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

#73

Post by asutekku »

neximo64 wrote: post #68
asutekku wrote: post #50

Earlier quoted context omitted.

Just because someone worked free on something does not mean it’s suddenly free of criticism. I’d say it’s healthy to criticize even these projects.

When that criticism is one describing a lacking support for someones issue then yes it is a problem. Its basically a way to coerce developers to give free support against bad reviews.

I don’t think software that has major issues (individual negative feedback about missing features will be filtered out as noise in the average ranking so this does not apply to that) should be left uncriticized just because it is made by someone for free.

On the other hand, good software that people like will thrive because of this.

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

#74

Post by jehna1 »

liorgrossman wrote: post #6
pragmaticivan wrote: post #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.

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…

I think a very good metric would be the number of maintainers of a package and how well funded they are.

E.g. React has a huge resource pool and people are getting paid for development, while some (most?) packages are single dev with no funding.

Perhaps making this kind of metrics visible would introduce some humility for people pressuring latter maintainers.

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

#78

Post by liorgrossman »

type0 wrote: post #63
liorgrossman wrote: post #59

Earlier quoted context omitted.

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" that developers can choose. Problem is that every maintainer chooses slightly different keywords, so it becomes ineffective as a tool for discovery. We still haven't fully figured out what the optimal solu…

> We still haven't fully figured out what the optimal solution might be like. Recommender system based on the kind of keywords in the description, starred project from main contributors etc

I think it would be a good start, but would still require some human vetting. We played with some simple NLP solutions (trying to run TF-IDF on the keywords/description/readme of packages to determine the category), the results weren't great honestly, so we opted of curating everything manually for now.

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

#79

Post by liorgrossman »

jehna1 wrote: post #74
liorgrossman wrote: post #6

Earlier quoted context omitted.

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…

I think a very good metric would be the number of maintainers of a package and how well funded they are. E.g. React has a huge resource pool and people are getting paid for development, while some (most?) packages are single dev with no funding. Perhaps making this kind of metrics visible would introduce some humility for people pressuring latter maintainers.

That's a great point. Showing project funding is something we had in mind (and in the mockups) but didn't make it to the MVP. We would probably have to integrate with Open Collective and other data sources.

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

#80

Post by aflag »

liorgrossman wrote: post #56
aflag wrote: post #53

It'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.

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 automatically is more tricky (sentiment analysis, which would be amazing, but we don't have the resources to do that well). For now, one of the things we might do is to ask people to specify…

When a user rates a library, they should really be rating a version of it (even if the latest is always assumed). As time passes and new releases are made, ratings over time could indicate whether the project is getting better or worse.
Post reply on HN