Launch HN: Openbase (YC S20) – reviews and insights for open-source packages - <AUTHOR> Hi everyone! I'm Lior, one of the makers of Openbase (https://openbase.io). We help developers choose the right JS package for any task - through user reviews and insights about packages' popularity, reliability, activity and more.
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.
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/minor versions, average time to resolve issues and PRs, percent of commits by the community, dependency insights, and more. Here's what the insights page looks like: https://openbase.io/js/react
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've already manually curated several hundreds categories, such as CSS frameworks, OAuth packages, and HTTP request libraries: https://openbase.io/packages/best-javascript-css-framework-l... 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.
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 "Great documentation", "Performant", and "Hard to use" (check it out: https://openbase.io/js/vue), and are looking for ideas for more badges.
We found that many maintainers want to promote their packages, and unfortunately, there aren'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/SaaS company that wants to earn developers' mindshare, or a software firm that wants to showcase their expertise. We'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.
In the good ol' 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't believe two decades later, the JavaScript ecosystem has gotten so huge and complicated, that we've actually built a startup to help you navigate this mess. Strange world, isn't it?
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? <comment><USER2> What's the business model to get paid for something like this? Alternatively phrased, how is this a sustainable business?

And how do you beat Microsoft from melding in this functionality into GitHub / NPM? The friction would so much lower (existing GitHub account) and they can place the information directly on the project pages.

<comment><AUTHOR> 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.

</comment></comment><comment><USER3> On one hand, this is fantastic and desperately needed. I've wanted something similar for years.

On the other hand, I'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's actually a pretty well-liked project! By making such a service you take on a lot of responsibility here.

<comment><AUTHOR> 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.

</comment></comment><comment><USER4> 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.

<comment><AUTHOR> 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?

<comment><USER5> 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.

<comment><AUTHOR> 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.

</comment></comment></comment></comment><comment><USER6> I'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's an mvp but Package results sorting should be there. Reviews would definitely help but I'd also prefer to see likes/upvotes on those reviews to get extra validation.

On a side note how are you ensuring that all popular packages should be included in your database? Otherwise it wouldn't make sense if user needs to crosscheck on google/npm/github like in this case of rendering table.

I'll be regularly using openbase for package discovery. Wish you all the best!

<comment><AUTHOR> 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.

<comment><USER7> Ruby toolbox has a wonderfully simple way of crowdsourcing it -- categorizing a package is as simple as submitting a small yaml PR, e.g. [https://github.com/rubytoolbox/catalog/pull/417/files](https://github.com/rubytoolbox/catalog/pull/417/files)

<comment><AUTHOR> 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 solution might be like.

<comment><USER8> > 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

<comment><AUTHOR> 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.

</comment></comment></comment></comment></comment></comment><comment><USER9> 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'?

<comment><AUTHOR> Thank you for your feedback!

1\. Nope, we currently have no way to edit what's in the overview page, so unfortunately you'll need to edit your README file to add additional links.

2\. In general, we're going to use an approach similar to BundlePhobia where we would show the gzipped/uncompressed file of the final file, but it does make sense to allow maintainers to flag this (and other information) as wrong.

3\. Our search engine is still work in progress. We started with the npms implementation, added additional layers of information from our dataset, and will iteratively add more and more factors to search results ranking. Unfortunately, we still can't grant for a specific package to be shown in the search autocomplete. We are, however, adding a "search result page" that would show more than the 9 results that you see in the autocomplete.

</comment></comment><comment><USER10> Does this include typescript projects? i couldn't find my own.[0]

Also, I can see my two most popular packages ( 40 stars[1] and 14[2] respectively), and I've realized that not updating them frequently probably hurts.

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.

I am also sad that things that I worry about, like testing, and bundle size are nowhere to be found.

But overall, great idea. Keep at it!

[0]:[https://github.com/ldd/vscode-jq/](https://github.com/ldd/vscode-jq/)

[1]:[https://openbase.io/js/gatsby-source-github- api](https://openbase.io/js/gatsby-source-github-api)

[2]:[https://openbase.io/js/react-tech-tree](https://openbase.io/js/react- tech-tree)

<comment><AUTHOR> 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 (sometimes the same person shows up as 2 different GitHub users, you can see that on GitHub too).

Bundle size is a big one for us, highly prioritized.

Testing isn't, though, what would you like to see about testing that isn't covered by badges? (e.g. test coverage, passing/failing, etc.)

<comment><USER10> aha! covering npm packages makes sense. I briefly forgot that I hadn't publish that one on npm. I wonder if vscode extensions are published on npm... umm...

I'm glad you have all those future features planned.

As for testing, I think that badges are often times not enough. I'd like to see if tests exist at all in the first place, and the quality or helpfulness of those tests. But maybe I'm in the minority for that, so ask other users for confirmation.

:D

<comment><AUTHOR> 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 looking for now. This will help us better model this feature if we end up implementing it.

Thanks for the feedback!

</comment></comment></comment></comment><comment><USER11> 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't think that's generally a good metric to promote as a top level metric obviously, but it would be interesting way to slice and dice projects.

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.

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.

<comment><AUTHOR> 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.

</comment></comment><comment><USER12> This is cool and I appreciate software development insights is getting some love. Full disclosure, I wouldn't say I'm working on the same thing, but we definitely have some overlap, when it comes to software development insights, which is gaining steam.

Your dashboard gave me some interesting food for thought, so I'll do the same and share with you, some of the things that I'm working on, that you are free to incorporate into openbase.

[https://imgur.com/Y06Tk3f](https://imgur.com/Y06Tk3f)

[https://imgur.com/Yjk2dzR](https://imgur.com/Yjk2dzR)

[https://imgur.com/RJw4ygS](https://imgur.com/RJw4ygS)

[https://imgur.com/xXi9EMd](https://imgur.com/xXi9EMd)

[https://imgur.com/nROCA0O](https://imgur.com/nROCA0O)

[https://imgur.com/xhb2haD](https://imgur.com/xhb2haD)

[https://imgur.com/sZ2YpIM](https://imgur.com/sZ2YpIM)

[https://imgur.com/HVSNhS0](https://imgur.com/HVSNhS0)

[https://imgur.com/TnInleD](https://imgur.com/TnInleD)

My focus is not on the discovery part, which you guys are working on, but rather, I'm more focused on providing "business intelligence" for the software development lifecycle.

I do agree with you that code metrics can only tell you so much, as it's not really meant for discovery. Code insights might provide things like stability, investment, complexity, etc., but like you said, you can'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.

<comment><AUTHOR> 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?

<comment><USER12> > Looks like quite a lot of work too, kudos!

Thanks. I don't think people realize how complex it is to generate actionable code insights. Indexing code is easy, indexing history is an order of a magnitude more difficult, in my opinion.

> Is it in production with some customers?

No, the product isn't finished yet (I pivoted a bit from my initial idea). My goal is to have it ready by the end of this month, so that I can start indexing and making the indexed information publicly available. I was hoping to have a docker image/bare metal install packages available by the end of this month, but I don't think this will be feasible.

Right now I'm continuously indexing 4,000 repos, but the challenge is really with GitHub and rate limits. When I have the public site up and running, I'll reach out to GitHub to see what can be done, as I would like to make the indexed information freely available for anybody to tap into, including Openbase, if I'm capturing things that you guys aren't.

<comment><AUTHOR> 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!

<comment><USER12> > Limiting most of our graphs/reporting to the past 3 years (some repos are > pretty old) *

I really need the entire history, so limiting time ranges isn't possible. The biggest issue is really with cloning/fetching, since GitHub doesn't like people synching thousands of repos on a daily basis. Outside of those things, my search and analytics engine doesn't really need GitHub, since GitHub is unable to provide the data that I need anyways.

I talked about it before, but what I'm really doing is moving Git's history into SQL (postgres in my case) and Lucene, so that I can slice and dice its history, to surface developer insights. Hence me calling it "business intelligence" for your codes history.

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

Thanks and I think your product has potential as well and you should look at the Enterprise angle. Discovery in large companies is actually a serious problem. Companies really need a single place that they can go to, to see all that is available.

GitHub, with their "Discuss" feature gets you part of the way, but companies still need a centralized place that can help them easily discover/discuss what is available internally.

</comment></comment></comment></comment></comment><comment><USER13> Immediately went looking for how to be a reviewer or who reviewers currently are (vetted), but didn't find anything? Clicking into a package I'm invited to leave a review where I see it'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'd rather defer to a proven community (like Debian's package maintainers) for guidance on JS packages. That's not a thing today, so maybe this project is a good first step.

<comment><AUTHOR> 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.

<comment><USER14> I was going to ask how you plan to prevent fake reviews, but this mostly answers that. Curious to see where you'll go after being stretched too thin.

<comment><AUTHOR> 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 do this ourselves, we're going to bring on additional team members to help with this, and once this is not enough, we'll have to use some combination of moderators (not very scalable), crowdsourcing (let users report suspicious reviews), and technology (identify and surface suspicious reviews).

We honestly don't know yet, but we know it's going to be a priority.

</comment></comment></comment></comment><comment><USER15> How are libraries added to a category? Manual? Eg. [https://openbase.io/packages/top-javascript-frontend- framewo...](https://openbase.io/packages/top-javascript-frontend-framework- libraries) seems very lacking.

Side note, selecting frontend frameworks from the sidebar gives the same list but the URL stays [https://openbase.io/categories](https://openbase.io/categories) \- URL should update.

<comment><AUTHOR> Indeed, currently it's curated manually! Would love to get suggestions for more libraries we can add to that category!

You're right about the selecting categories from the sidebar not updating the URL, we haven't implemented the routing yet, that is something that we'll implement soon.

<comment><USER15> I think it's a good idea to include ones that stands out from rest of the pack.

[https://github.com/sveltejs/svelte](https://github.com/sveltejs/svelte) and [https://github.com/ryansolid/solid](https://github.com/ryansolid/solid) stands out by being the only 2 that are compiled to standard js, so no framework is loaded at runtime.

Speed is important too and [https://github.com/infernojs/inferno](https://github.com/infernojs/inferno) (and solid above) is well known for speed and is backed by benchmarks.

Not sure if you want to add more beyond this point since a few more will push the boundary to just include everything which is over 100 nowadays.

<comment><AUTHOR> Awesome, thanks for the suggestions. Not sure how we missed Svelte (?!) I'll be sure to add those to the frontend framework category

</comment></comment></comment></comment><comment><USER16> 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.

Congrats on the launch!

<comment><AUTHOR> 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!

</comment></comment><comment><USER17> I would really love if this displayed the bundle size of each package (a la bundlephobia[0]).

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

[0] [https://bundlephobia.com](https://bundlephobia.com)

<comment><AUTHOR> 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?

</comment></comment><comment><USER18> Nice, now we can review someone's open source contributions they usually worked for free on.

<comment><AUTHOR> 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't have a dedicated platform to do that.

Like most developers, I've been using dozens of open-source libraries, it's natural that I'll form some sort of opinion about them. If I'm like most developers, I'll even have some very strongly held opinions and preferences.

I will like some packages, and hate others. I'll find some documentation great, and other unreadable. I will insist one project is complex, and the other is easy to use. That's all fine.

IMHO, the fact that a piece of software was created for free, doesn't mean I shouldn't have the right to express my experience and opinions about that software, good or bad. With Openbase, we just want to give developers the ability to easily learn from the experience of other developers, and share their own experience with various libraries.

<comment><USER18> I'm curious about whether your project would make more events like what happened with the rust actix-web library.

Short story if you're not aware: It is the fastest web library out there, but the maintainer _quit_ open source entirely. I fear projects like yours would just make it worse.

This may sound harsh: your rebuttal doesn't really address the issue it just tries to justify 'live with it'

</comment></comment></comment><comment><USER19> Do you plan to provide an API to build cool stuff around this? Congrats on the launch.

<comment><AUTHOR> 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.

</comment></comment><comment><USER20> 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.

<comment><AUTHOR> 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 a version whenever they rate/review a package (or somehow deduce that automatically based on the date of review, which would not be as accurate...)

<comment><USER20> 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.

<comment><AUTHOR> Wow, showing a graph of user ratings over time would be amazing (once we have enough data)

</comment></comment></comment></comment><comment><USER21> Do you have a plan to expand to other projects, not related to JS?

<comment><AUTHOR> 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...](https://docs.google.com/forms/d/e/1FAIpQLScexiehdwDWJwxZJym85iWocyPyvOB4V5-07PS2QZ59NMj1FQ/viewform)

</comment></comment><comment><USER22> This looks like a lot of work. How will Openbase make money?

<comment><AUTHOR> 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.

<comment><USER23> That seems like an interesting choice.

As an individual, I don't think I'd ever pay for promotion of a package unless I had moved my career to providing support for open source packages.

I can imagine companies using it as a marketing exercise for their open source efforts. That might not be a bad thing as packages backed by companies tend to be better, more mature, have better support.

However I can see this then being abused by SaaS companies using this as a way to advertise their service. i.e. they provide a package that integrates with their service, so while the package is open source they are making money on the use. I can imagine this significantly degrading the quality of packages.

<comment><AUTHOR> 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.

</comment></comment></comment></comment><comment><USER24> Very cool idea - Surprised there isn't already someone doing this. Annual surveys are interesting but a bit of a slow feedback loop.

<comment><AUTHOR> 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), but cannot cover the hundreds of different categories that we use on a regular basis (HTTP request library, logging library, tooltip library, XML parsing library, etc.)

</comment></comment><comment><USER25> I hate to be that guy, but should I switch to a browser with javascript just to see the landing page?

<comment><USER26> Frontend javascript keeps the bubble economy going

</comment></comment><comment><USER27> Looks great. Can you add testing coverage as one of the metrics?

<comment><AUTHOR> Thank you. You mean a percentage (77%), like the one you usually see on a README badge?

<comment><USER27> Yup, exactly. It gives confidence in using the library

</comment></comment></comment><comment><USER28> Kudos for Lior and the team, great product!

<comment><AUTHOR> Thanks!

</comment></comment><comment><USER29> Cool. Does it include who backs a project?

<comment><AUTHOR> Not yet.

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

</comment></comment><comment><USER30> Do you provide source code auditing?

<comment><AUTHOR> No auditing capability at the moment, sorry. We focus on helping developers discover and choose packages.

</comment></comment><comment><USER31> 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.

<comment><AUTHOR> 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.

<comment><USER31> Best of luck, sir!

<comment><AUTHOR> Thank you!

</comment></comment></comment></comment><comment><USER32> Good Initiative

<comment><AUTHOR> Thank you!</comment></comment>


Trader sells 100k ETH, lowest price at $0.10, fulfilling entire GDAX order book - <AUTHOR> http://imgur.com/a/qhNeE <comment><USER2> Fat finger?

<comment><USER3> Or extracting value before the big coming changes?</comment></comment>


Were There Dark Ages? - <AUTHOR> http://slatestarcodex.com/2017/10/15/were-there-dark-ages/ <comment><USER2> Disclaimer: am an historian and agree with the basic premise of OP. Without a doubt, it would be preferable to have been born in 100 CE as opposed to 800 CE, in most parts of Christian Western Europe. But I think he dismisses point #1 far too hastily. Go a little bit south of the Visigoths, and you have one of the world's largest libraries to date and a city to rival ancient Athens in size (Muslim Cordoba).

The point I try to make when I teach this stuff is not that there was no period of decline in Christian Western Europe after the fall of the Western empire. That's a given. But the culture of the Greeks and Romans also had a home in places like Morocco, Afghanistan and Egypt. Those places were doing great during the "Dark Ages" and were just as much the inheritors of the Classical world as, say, Germany and Ireland.

In other words: fixating on a Dark Age that only befell something like 1/4 of the zone of Greco-Roman influence gives a misleading impression because it imposes much more modern geographic boundaries. Many of those "lost" classical texts rediscovered in the Renaissance were still readily available in places like Isfahan and Shiraz. Likewise with population: I would wager that, taking a century-level view, the regions encompassed by Alexander's empire increased steadily in urbanization and GDP from his time to that of the Mongols.

<comment><USER3> > I would wager that, taking a century-level view, the regions encompassed by > Alexander's empire increased steadily in urbanization and GDP from his time > to that of the Mongols.

There is evidence of a medeival decline, even in those areas, although obviously not as bad.

In _" Why The West Rules, For Now"_, Ian Morris defines "The West" very broadly, and definately includes everything you are talking about. He then comes up with various metrics which are not averages, but which focus the most successful part of the region (e.g. population of the biggest city).

Not surprisingly, the most successful parts of the west by his reckoning, were in the Islamic world during the middle ages. But even then his overall metric shows a medeival dip for the west, which his "east" (aka China) did does not see.

<comment><USER2> Before the Mongol invasions? That would surprise me, if so. Would be interested to see his evidence, if anything from the book is online.

<comment><USER4> I haven't read this book, but it is on my list.

This data would surprise me too, but the author is fairly well credentialed and has done reasonable work at estimating this kind of thing before. He is one of the authors of [https://classics.stanford.edu/publications/cambridge- economi...](https://classics.stanford.edu/publications/cambridge-economic- history-greco-roman-world)

His work on city size seems to be in this PDF, pages 109-117: [http://www.ianmorris.org/docs/social- development.pdf](http://www.ianmorris.org/docs/social-development.pdf)

I'm far from an expert on this. The only thing I noted was that his estimate of 125K in 1000CE Baghdad is lower than I expected. He argues it may actually have been lower given the documented size, and he notes the 500K-700K estimates for Baghdad imply a much higher density to anywhere else at that time.

I'd note that I don't see the OP's point (that population declined in the Muslim cities during this period) reflected in the numbers I'm seeing in this document. That is mostly because it isn't clear about the whole area population as opposed to the largest cities.

</comment></comment></comment></comment><comment><USER5> In the West we must give thanks to the Irish monasteries, where manuscripts were preserved that were lost in the rest of Europe to the chaos of the _Völkerwanderung_ , and to Charlemagne, whose advisor Alcuin brought the knowledge back from his Islands. Heinrich Böll called Ireland "Europe's burning heart". Nonetheless, the amount of literature lost in Late Antiquity is staggering.

</comment><comment><USER6> it did take several centuries to create a framework for economic cooperation that works for large geographic areas and that was not based on the classical Greek regime of slavery (that might work as a summary).

For an individual of low birth serfdom seems preferable to slavery, however it must be more difficult to organise a 'big' economy on top of that

The western Roman empire needed grain from North Africa and the Middle East - it needed ships to transport all that and would pay with silver from Spanish mines - you need a slave regime to maintain all that. A system with more independent actors that achieves the same level of trade / cultural exchange is inherently more complex (needs more complex system of laws, finances, everything) , but is in turn more scalable.

I think Europe 'won' because it was a distributed system. A country/ruler can go bad, but as a whole connected by trade and cultural ties it kept going further (each ruler had to keep up if not to be swallowed by the neighbours) . However big unified realms like China or Russia all rise and fall as one entity - and it takes longer to recover from a big crisis.

</comment><comment><USER7> Meh. In Roman times, France, Germany, Spain, and the British Isles were all relative backwaters (Germany not even that) that didn't have much innovation anyway, so considering those places 'darker' in 500-1000CE is somewhat misleading. Culture, money, and learning was in the central mediterranean and eastern Roman empire.

<comment><USER8> >so considering those places 'darker' in 500-1000CE is somewhat misleading

Standards of living declined dramatically, war and violence were more widespread. Most people would call that darker.

</comment></comment><comment><USER9> Ctrl-F "Byz..."

Ctrl-F "Consta..."

No offense, but this dude should stop posting anything history-related. Historical memes aren't history.

<comment><USER10> The linked article explicitly makes this point:

"Every other historical age name is instantly understood by everyone to refer to both a time and a place. [..] let's just agree to call it the Western European Dark Ages, as long as we can also agree it existed and was bad."

<comment><USER9> No, let's not.

Talking about the Dark Ages and failing to mention the Eastern Roman Empire is like talking about the Cold War and failing to mention the USA.

It means that the article is a kaleidoscope of mismatched, unconnected memes instead of something holistic and grounded in reality.

Some reality-based facts:

a) The western part of the Roman Empire collapsed a few centuries prior to the fifth century.

b) The southern shore of the Mediterranean and the Middle East collapsed during the Muslim invasions. (And never recovered, even to this day.)

c) The eastern part of the Roman Empire only started collapsing during the 13th century, give or take.

d) The flow of civilization from the eastern part to the western parts of the Roman Empire was blocked by Muslim piracy. (There is no overland route between Italy and Greece.)

e) The German-speaking parts of Europe were never any part of any Roman Empire, and saw no collapse. (Only improvement.)

f) Spain has its own history and its own historical cycles.

</comment></comment></comment><comment><USER11> To be fair WW1 wasn't invented until WW2 came along, before that it was mostly the "Great War"

</comment><comment><USER12> "The Dark Ages" is one facet of the extreme Western Europe focus on history taught in much of America and presumably Europe. I had lessons on Greece and Rome, then on the Norman invasion. Everything I was taught has this extreme slant, but combined with learning almost nothing about anywhere during the Dark Ages you're left thinking nothing happened.

So yes, if you're goal is an exclusively Christian Western Europe focused view of history, the term is fine. If that isn't your stated goal, why use it over Early Middle Age?

<comment><USER13> That sounds like saying "well, if you only care for Russia, Ivan the Terrible is surely an appropriate term, but he wasn't particularly terrible for Africa or Americas, so using this nickname betrays you are exclusively interested in only Russian history and don't care about the rest, otherwise you'd call him Ivan the Fourth Vasilyevich!". Doesn't sound very convincing to me.

<comment><USER12> You're arguing from a position of someone with some history knowledge, which is not the problem. Knowing that Ivan the Terrible was a Russian Tsar is uncommon, and if he comes up you probably will be exclusively focused on Russian history.

People don't know a ton about the Dark Ages either, but "Rome collapsed leading to the Dark Ages," and "The Discovery of America/the Renisance/The Scientific Revolution led us out of the Dark Ages" are often things you will have heard. And given the context you can hear them, it's not clearly referring to Western Christian Europe.

<comment><USER14> That non-historians often misunderstand the shape and scope of the Dark Ages doesn't seem like a problem of definition, but of widespread ignorance. People who elevate the discovery of America, the renaissance, or the scientific revolution to the degree you describe are not going to be dissuaded by any sort of renaming, because those views aren't factually based in the first place.

<comment><USER12> I started this off by saying it was one piece of a much wider problem. Calling it the Dark Ages can make your ignorance seem correct in a way that other names don't.

Calling them the Early Middle Ages gets rid of the false narrative of later events ending the Dark Ages, and it doesn't accidentally imply nothing happened anywhere. It's not going to end ignorance, just remove confusion. What reason is there to keep calling it the Dark Ages?

As for the isolated demand for rigor, I would not expect most people to know anything about the examples given. If I were talking about them, I would immediately add a qualifier explaining what they are. The Dark Ages are a more common term, being widely used outside of history.</comment></comment></comment></comment></comment>


An experiment. - <AUTHOR> http://blog.wereview.io/post/51722225667/an-experiment

<comment><USER2> For a second there I was thinking the experiment was to see how little information they could provide and still get people to sign up for their (rather ambiguous peer-review) service.

<comment><USER3> I seriously thought this as well, and would be interested to see results of this type of experiment. Kind of like an OBEY GIANT kind of campaign.

</comment></comment><comment><USER4> I'm sorry, but the lack of clear explanation and direction about what the product actually is does not make me want to give you my email address. If I were to see this page before first reading your post I'd definitely close the tab immediately.

</comment><comment><USER3> forrst.com is essentially that, except they had to get more specific. As a small operation, you almost have to appeal to a niche or you will have a hard time finding a clear market.

<comment><AUTHOR> interesting, thanks

</comment></comment><comment><USER5> Is it a werewolf webcam?</comment>


Ask HN: Is this a privacy/security issue with Gmail? - <AUTHOR> I've been using gmail for a long time and have just noticed something that is a bit concerning from a privacy/security standpoint.
When you compose an email to a valid gmail account, it will provide you with additional details of the account, if the user provides it, even if you have never corresponded previously via email. This works for emails with @gmail and also @somebusiness.
For example, go to gmail and compose an email to email@example.com, then hover over the address in the To: field.
You now know this is a valid email, who it belongs to, and a fairly decent amount if information about that person. <comment><USER2> GMail doesn't really "leak" information about e-mail addresses, it just displays any public information tied to that address's Google Plus profile.

Once upon a time, Google dedicated a massive amount of resources to launch a social network to compete with Facebook, Google Plus. When G+ launched, one of the "features" was linking your GMail account with your G+ account. G+ didn't really take off (obviously), but all Google employees were "strongly encouraged" to join, and the account you're looking at (firstname.lastname@example.com) belongs to former Google engineer, who does have a public G+ profile. If you go to plus.google.com and search for that e-mail address, it will bring up their profile page. If you know any GMail addresses that don't have public G+ profiles, you can verify their information isn't leaked.

Aside: G+ was the reason why Google Reader was killed #NeverForget

<comment><AUTHOR> If its tied to G+ then why does this work with business gmail domains as well?

<comment><USER3> They are probably using Google+ with their business gmail email address.

</comment></comment></comment><comment><USER4> It depends on what info the address owner shares with the public through gmail/google+. It's not a security issue if the owner consciously sets it.

In the good old days, there was a finger protocol you could use to find out info on the account. It was abused by owners not understanding it and sharing info inadvertently, and then behaving as if that info were secret (eg, existing, last log on, etc).

I wish we could go back to finger, rather than depending on particular services like Goog's.

<comment><USER5> > _It's not a security issue if the owner consciously sets it._

It depends on how conscious the decision was; were they explicitly aware that the information would be shared with the world at large?

</comment></comment><comment><USER6> Dude.yes.

They just this year stopped scanning keywords in your email body for advertising purposes.

I won't say don't use gmail,maybe the risk is acceptable to you. But I highly recommend paying for protonmail.

> When you compose an email to a valid gmail account, it will provide you with > additional details of the account, if the user provides it, even if you have > never corresponded previously via email. This works for emails with @gmail > and also @somebusiness

This isn't surprising,google probably thinks the usefulness of such a feature is more important than privacy of the recipient. This is their M.O., what little pseudo-privacy you get with a google product is via opt-out.

My mini-rant aside,as a business owner, I suppose google auto filling your contact metadata in that scenario would not be a bad thing(but then again, just about every controversial feature of a google product benefits business owners seeking to advertise on their platform)

<comment><USER7> > They just this year stopped scanning keywords in your email body for > advertising purposes.

Not true (except maybe for the narrowest readings of the phrase "for advertising"):

[https://news.ycombinator.com/item?id=17067151](https://news.ycombinator.com/item?id=17067151)

<comment><USER6> > "Google has decided to follow suit later this year in our free consumer > Gmail service. Consumer Gmail content will not be used or scanned for any > ads "personalisation after this change."

That's from the google blog post announcing the change. They scanned emails and supposedly now they've stopped

</comment></comment></comment><comment><USER8> I believe it's actually a "Google profile", although it got a lot of attention around the time of the Plus push.

At that time, Google cajoled and borderline tricked people into filling in their profile (e.g. "dark patterns): Name, a profile photo, etc.

They also made this information publicly accessible.

I recall, for a while, actively working to navigate all the Google UI dedicated to prompting me into filling out or supplying this information. (Particularly, I recall the photo part -- no thanks.)

I recall, also, a time or two following suggestions to navigate to my profile and check what was on it and whether it was public.

This all blurs together in my mind, somewhat, to similar efforts to fight the morphing Facebook UI and its attempts to gather and publicize my profile data. So, all the details are a bit vague in my memory, now.

Note, too, that you can -- or could, at times -- provide information regarding contacts that would appear in your own UI views. You could/can upload a photo for whatever contact, so that their presence in the UI is more "recognizable to you". And who knows.

Do I trust Google segregation/isolation of all these possible inputs to the profile-esque data it has on someone? Not really. Even where this isn't intent or malice, the various moving pieces of all their morphing projects seem rife for lack of knowledge as to effects, slip-ups, and neglect.

\--

P.S. Reading other comments here is causing me increased concern, on multiple fronts. What Docs (or "Drive" \-- whatever) may pop up for an address you start to share to. Whether bcc addresses are "hidden" but not removed from the copies going to other recipients. Etc.

P.P.S I did a quick test and am not observing the bcc leakage. As I replied elsewhere in this thread:

I just checked this and am not observing it -- at least, not between various Gmail accounts and checking/dowloading the "original message" using the Gmail web UI.

</comment><comment><USER7> My favorite "feature" on these lines is the fact that it displays the BCC list at all the recipients.

'Cause the "B" in "BCC" doesn't stand for "blind". It stands for "Ha ha! You told me a secret and I blabbed and now you're embarassed/fired! Can we still be friends?"

<comment><USER8> I just checked this and am not observing it -- at least, not between various Gmail accounts and checking/dowloading the "original message" using the Gmail web UI.

</comment></comment><comment><USER9> I've flagged similar as a bug to Google. You can use their docs share function to get non-publicly available names from email addresses and confirm if they are an existing email.

To test I setup a spreadsheet with randomly generated words and it does grab names for you. Personally I feel a bit annoyed Gmail would share my first/surname to people if they test a non-identifiable email address. Also I believe scams could use this to improve their success rate if they can insert peoples names to false business emails type thing.

But according to Google this is 'a feature' not a bug.

</comment><comment><USER10> It means they have a Google+ profile. If you remove your profile, the info should not shown on Gmail.

</comment><comment><USER11> I think it's information that is technically public.</comment>


Bloomberg chief editor: We publish too many mediocre and long enterprise stories - <AUTHOR> https://talkingbiznews.com/they-talk-biz-news/bloomberg-eic-micklethwait-we-publish-too-many-mediocre-and-long-enterprise-stories/ <comment><USER3> The point of the chief editor is so true that I'm surprised to read that from them.

I have noticed that a lot of times with this kind of web media.

\- You have a clickbait title like this: "How a normal guy managed to hack WallStreet with a simple pen"

\- Then, you have one page of interesting introduction on the topic but without the reply to the title question.

"In november 2018, WallStreet was busy with the introduction of xxxx, and suddenly a problem happened, everything went black. To understand, wallstreet works with computers that are connected with a modern system... 300 words ... and on that cold night of the 23 nov 2020, one man John Crowford destroyed all of that."

\- Then you have 10 pages of useless crap and fake intervews about the childhood of the guy and a lot of things that are not interesting, and not related to the subject.

"His mother was blond, she liked to eat fries. But despite that, John Crowford liked to eat popcorn. So much that his friend reported that, one time, he stayed at a movie theater for a whole day just to eat popcorns ... Studies at the yyy school were ok, but he followed them without passion until he met Carolinas Brocolis a hot night of summer 1992. Together they got 3 kids ... he was not supposed to live in New York as he was born in California, but he found a job there, ..."

\- And then, you finally have the explanation that is, most of the time, short and straightforward.

"So, he was hired as a Janitor in Wall Street, and accidentally put his pen inside the holes of a power plug, resulting in a major power failure. THE END"

After reading such a story, either you did skip to the end directly, or you are very angry to have lost so much time reading useless things.

<comment><USER4> This is merely a consequence of SEO. Have you tried searching for recipes? It's absolutely miserable. I don't need irrelevant life stories-- show me the ingredient list and instructions.

<comment><USER5> I've always wondered why someone isn't going around taking other people's SEO- fluffed recipes and just re-formatting them onto standalone fluff-less pages, with _good, standardized_ formatting:

• an ingredients _table_ rather than an ingredients _list_ (i.e. where quantity, unit, and ingredient name are columns; and quantity is right- aligned, like any other numeric column in Excel); with sensible units that don't assume their regional growing conditions or food-product design carry over world-wide — so no "sticks" of butter, no "glugs" of oil (from what spout diameter?), no "drops" of flavorings, no "inches" of ginger, etc. Give me volumes! Weights! _Molar concentrations_! (Half-kidding on the last one.)

• put all references to an ingredient in the steps in bold, and always use the same name for an ingredient that the ingredients table itself uses.

• no implicit ingredients (yes, put the salt and water that the pasta gets boiled in, into the ingredients! Let me _mise en place_ without reading the steps!) Also, don't say "200g sugar" if you mean "100g sugar for the cake sub- recipe; 100g sugar for the frosting sub-recipe." Break those out, so that the fact that those separate quantities should be _kept_ separate is _explicit_ , rather than something you must implicitly gather from the steps.

• or go further and make the ingredients table into its own kind of "pre- recipe" — a sequence of _preparation steps_. Not only "measuring things into bowls", but also steps such as: explicitly buying things day-of if they're best fresh; or defrosting, if the ingredient is often kept frozen (with defrosting times added to the total amount of time the recipe takes!); etc. Write down exactly what a chef would train their prep cooks to do for them in the preparation phase of this recipe.

• a print stylesheet that makes the webpage come out as a single compact printed page, with a big title, large text, a small picture of the finished product, and no dead space or colored backgrounds (or alternately, a link to a single-page pre-generated PDF with even-more exacting formatting.) I don't want my iPad (that keeps going to sleep and must be woken up with dirty fingers, and can get splattered by oil) in the kitchen; I want to print recipes and put them in transparent binder sleeves. Give me recipe pages I can both easily flip through, and easily find. Let me build a _quality_ printed cookbook, one page at a time, out of my favourite selected recipes from your site.

• a universal "set serving size" client-side Javascript adjuster, which not only manipulates the ingredients but also the correct timings for steps that depend on weights (e.g. defrosting, searing.) None of this "until 165C internally" nonsense; I always buy the same cuts of meat, so calculate the time required for _my_ food to come to temperature, and then tell it to me. Maybe also insert the adjusted amount of the ingredient being used into the text of the steps, so it actually says "add the milk (1tbsp)" rather than just "add the milk." (The ingredients list is for shopping/prep-phase; I should be able to _cook_ without referring to it!)

• each ingredient name in the ingredients table should have a side-link to a page that talks about substitutes for that ingredient, and how to adjust recipes for that substitution. Ingredients with common substitutes should offer an adjustor select-box right there in the ingredients table, where tweaking it changes the recipe appropriately. (Which means the recipe can now include things that are highly-dependent, e.g. it can ask you what pasta you're using, and then _embed in the steps the correct cooking time for that type of pasta_ ; and since the recipe knows what kind of recipe it is, it can specify the al-dente time target if it's baked pasta, or the fully-cooked time target if it's a pasta salad.)

• When a recipe is actually just an arbitrary linearization of a few _concurrent_ sub-recipes (e.g. a dish to cook, and a sauce you prepare and then pour over it right before serving), make this clear. Draw boxes around the sub-recipes' steps, and number those boxes. Then put a little boxes-and- arrows workflow diagram for how the numbered sub-recipes relate to each-other at the top of the steps. Represent each sub-recipe in the diagram as a box with a height proportional to how long its steps take—such that you can eyeball which sub-recipe you'll be done with first. Label the boxes with timers that should be set at the beginning of them (because almost always the end of a box is "take off heat" or "take out of oven.")

I'd bookmark a site like that directly, and use it religiously in preference to any other recipe provider.

<comment><USER6> > I've always wondered why someone isn't going around taking other people's > SEO-fluffed recipes and just re-formatting them onto standalone fluff-less > pages, with good, standardized formatting:

Because they'd likely run afoul of copyright laws. A recipe in and of itself doesn't generally qualify for copyright protection, but a recipe cushioned in prose can be a copyrighted literary work. So anyone ripping the recipe out of it would infringe on the copyright of the literary work itself. See "How do I protect my recipe?" on [1].

[1] [https://www.copyright.gov/help/faq/faq- protect.html](https://www.copyright.gov/help/faq/faq-protect.html)

<comment><USER5> Copyright applies to the prose itself, though—the word choice and ordering.

A site like the one I'm describing doesn't have to use the same _words_ the original site uses. In fact, I'd really hope it wouldn't, since these sites almost never use a standardized vocabulary, and in fact try as hard as they can to make their recipes into _interesting prose_ (i.e. using a different word in reference to something each time they reference it) at the expense of clarity.

The "boiled-down form" of these recipes, would look less like prose text, and more like an RDF graph linking ingredient-noun vertices together using action- verb edges.

In fact, now that I think about it, it could probably be stored in a format machine-readable enough to function equally well as machinima choreography for a "cooking simulator", i.e. an HTML5 canvas app with an engine approximating a cooking game (e.g. Cooking Mama) but without the "game" part.

Such a "timeline view" of the recipe could actually keep track of the collection of pots/pans/bowls/etc. required in the recipe, and then visually display the current state of what's in each of them at each step, as you scroll through each step in the recipe's timeline. Like a visual debugger, for food.

The textual representation of the recipe would just be generated from that same non-textual data format, via a simple structured NLP rule-set. (Yes, you could instead throw the sort of algorithms they're using to generate baseball news coverage[1] at the problem, but we want _standardized_ text, not _stylized_ text.) Bonus: i18n for free. The normalized recipe data isn't "in" any language, so it's equally easy to write a ruleset for generating recipe- step prose that _is_ in any language.

The resultant text of such a generative process shouldn't be copyright- infringing, even if it matched some other recipe word-for-word by coincidence. When you "extract" only the bare facts from a work and discard the rest, you're not making a derivative work; a work of yours that employs those "extracted" facts is _not_ a derivative of the source of those facts. (If it were, then every summary or review of a work, would be in violation of the copyright of the work it's summarizing or reviewing, since the bare facts referenced were gleaned from the original work.)

[1] [https://venturebeat.com/2016/07/01/associated-press- expands-...](https://venturebeat.com/2016/07/01/associated-press-expands- sports-coverage-with-stories-written-by-machines/)

<comment><USER6> Copyright applies to the literary work as a whole, and protects derivative works based on it[1].

In this case it's true the derivative work (the recipe) wouldn't be copyrightable, but that doesn't absolve it from being considered a copyright violation of the original work.

If you can show you independently created that recipe, then you're protected from the above assertion that it was a derivative of that copyrighted work. But if you're compiling a database of normalized recipes via scraping recipe content online, it'd be pretty easy for a copyright holder to establish this argument doesn't hold water.

[1] [https://copyright.uslegal.com/enumerated-categories-of- copyr...](https://copyright.uslegal.com/enumerated-categories-of- copyrightable-works/copyright-for-literary-work/)

<comment><USER5> Aren't prose recipes a kind of program source-code; and aren't the underlying ideas of their steps, algorithms? The law says you can copyright source code, but not a program's underlying algorithmic semantics[1].

What I'm talking about here, is effectively "extracting the semantics of someone else's source code/recipe, in a way where humans are "firewalled off" from the particulars of the original prose of the code/recipe; and then using the described semantics to write your own code/recipe that has those same semantics."

This is explicitly something that's been decided as _not_ copyright- infringing; which is why IP lawyers have to go after cases where there was literal plagiarism of source code, however small.

The big example of this is _Google v. Oracle_ , where API header files used in Android were literally plagiarized from OpenJDK. Google argued that this was fair use, as there was essentially no other form these files could take while retaining Java compatibility. But this argument was shut down/never resolved in their favor.

All Google had to do, in the end, to avoid infringement, was to do a ground-up rewrite of those Android API header files (which ended up almost exactly the same as they were before the rewrite.) Note that they still rewrote them using _an understanding of the bare facts that those header files contain, that could only have been gained by reading the original header files themselves_. And yet the new derivative work, being "not literally plagiarism", was no longer considered an infringing derivative work.

[1] You can _patent_ algorithms (sort of, as business processes), but that's a different thing. Nobody's ever going to sue a recipe website for patent infringement, even if they described Nestle's patented chocolate-enrobing technique, because a _description_ of a patented process is not a _use_ of that patent. Patents are inherently public information, and people can share and reprint the information in them around all they like. Instead, a patent owner would only sue other companies who _used_ the patented technique for commercial gain, for not first acquiring a license for the patented technique. (Google never sued bloggers for describing the PageRank algorithm; but up until last year, Google _did_ sue other search-engine companies for _implementing_ PageRank without a license.)

<comment><USER6> True. But in this case, you'd have to ensure you went through the process of truly re-implementing the algorithm of the recipe, and stripping out all non- algorithmic components of the instructions. For example, a step in an icing recipe[1] may say something like:

 _Gradually beat in just enough milk to make frosting smooth and spreadable. If frosting is too thick, beat in more milk, a few drops at a time. If frosting becomes too thin, beat in a small amount of powdered sugar. Frosts 13x9-inch cake generously, or fills and frosts an 8- or 9-inch two-layer cake._

The only "algorithmic" component to that step is that you add milk. The fact that you do so gradually, use a beater during the process, how you identify when you've added enough, how to correct for deviations in viscosity of the mixture, etc are all part of the "source code" rather than the algorithm and wouldn't be something you could republish without being considered a derivative work.

The recipe without those contextual components may still be useful for those sufficiently familiar with baking, but for many people following a recipe, they'd likely need such contextual components to follow the recipe successfully.

[1] [https://www.bettycrocker.com/recipes/vanilla-buttercream- fro...](https://www.bettycrocker.com/recipes/vanilla-buttercream- frosting/39107a19-be94-4571-9031-f1fc5bd1d606)

<comment><USER5> > The only "algorithmic" component to that step is that you add milk. The fact > that you do so gradually, use a beater during the process, how you identify > when you've added enough, how to correct for deviations in viscosity of the > mixture, etc are all part of the "source code" rather than the algorithm and > wouldn't be something you could republish without being considered a > derivative work.

I would disagree. Here's what I learned from your quoted paragraph, expressed in pseudo-Prolog:

\- beatInto(FrostingMixInBowl, Milk, $BeaterSpeed) => increaseQty(FrostingMixInBowl, Milk).

\- beatInto(FrostingMixInBowl, IcingSugar, $BeaterSpeed) => increaseQty(FrostingMixInBowl, IcingSugar).

\- invProportional(viscosity(FrostingMixInBowl), absorbancyPerUnitTime(FrostingMixInBowl)).

\- nonNewtownianViscosity(FrostingMixInBowl).

:. invProportional(absorbancy(FrostingMixInBowl), $BeaterSpeed). // implication from standard library

:. require(maxThreshold($BeaterSpeed)). // implication from standard library

\- invProportional(viscosity(FrostingMixInBowl), AmbientHumidity).

\- invProportional(viscosity(FrostingMixInBowl), AmbientTemperature).

\- proportional(viscosity(FrostingMixInBowl), currentQty(FrostingMixInBowl, Milk)).

\- invProportional(viscosity(FrostingMixInBowl), currentQty(FrostingMixInBowl, IcingSugar)).

\- target(viscosity(FrostingMixInBowl), centiPoise(10000)). //see [https://www.globalpumps.com.au/list-of-typical- viscosities](https://www.globalpumps.com.au/list-of-typical-viscosities)

...and then some stuff about how much frosting we're making here, but without the context required to translate those figures into absolute extruded surface area.

Anyway, do you see what I'm getting at with this? We're describing a _system of dynamic constraints_. What you generate from this "knowledge base" is an _action plan_ that routes you through the system of dynamic constraints to achieve the target (in this case, icing of a specified absolute viscosity.) The constraints are _generative_ , where constraints asserted together produce further constraints, and those constraints can be translated into structured- text warnings like:

• "the icing is too thick to absorb milk at faster than N mL per second; if you introduce it faster than that, the milk will bounce off the surface of the icing rather than absorbing, and probably splatter you in the face."

• "beating the icing too fast shears/aerates it, increasing its viscosity, making it unable to absorb anything, meaning that _anything_ introduced to the icing will bounce off the surface of the icing and splatter you in the face."

Such a system also allows the resolution of ambiguities, where instead of saying " _if_ the icing is too thick", it can know the variables that affect viscosity, and so just ask you to set those variables (i.e. the ambient temperature and rH value for your kitchen) either in your user preferences or at the recipe header; and take that into account to compute initial quantities for ingredients that should produce a viscosity in no need of further adjustment. (But it could also generate the structured text explaining what actions it knows about for this step that increase and/or decrease viscosity — you know, just in case you messed up and didn't follow its perfect robot plan.)

Note that this isn't super out-there tech. People build models that do these computations all the time. Which people? The operational engineers in charge of the day-to-day operations of baked-good and candy factories.

I'm just suggesting, in essence, a generalized domain-specific abstract machine for modelling _all_ such problems in an easy way (rather than rebuilding it half from scratch in spreadsheets each time), such that you could just as easily describe the dynamic-constraint system underlying a steak as one underlying a Mars bar.

...and then using all that just to emit recipe prose. :P

(But you could _also_ use it as the "mental model" a multi-purpose robotic kitchen could use to generate action plans, of course.)

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> This memo highlights a problem that I've noticed recently as the public debates the legitimacy and effectiveness of the media.

This chief editor is basically telling his people to write what readers want to read. But there's a difference between what readers always want to read and what may be necessary to read.

For example, if people only read what they wanted to read, how many people would really take interest in a possibly boring but important scandal? The Catholic Church sex abuse scandal comes to mind. It's impact was global, but it's not really related to domestic political battles or terrorism or whatever else really sells in the media these days.

The problem is worse now because news isn't sold as a broadsheet anymore, where subscribers might not read everything in an issue, but eyes are on all of the stories. Is that the case when everyone gets to pick a la carte from a website, especially when management like this is telling reporters to focus on what gets the most clicks?

<comment><USER8> > how many people would really take interest in a possibly boring but > important scandal? The Catholic Church sex abuse scandal comes to mind.

There's very little that is more attention grabbing than sex scandal. Except sex scandal involving children. Or one involving an large powerful institution around which political and culture war controversy (both internal and external to the institution) is constant, especially on sexual issues.

> It's impact was global, but it's not really related to domestic political > battles

Yes, it was, especially because the Catholic Church is perpetually engaged in those battles on sexual issues, and because the scandal immediately intersected with the debate on those issues, as well as ongoing internal organizational debates in the institution such as the role of celibacy and homosexuals in the clergy that directly overlapped with the political and culture war issues the Church is regularly engaged in.

So, yeah, worst possible example, even if one grants that you might have a generally valid point.

</comment></comment><comment><USER9> Articles in The Economist are usually a better investment of my time. I was originally introduced to the magazine by a teacher in high school, but I've come to learn that many other people weren't as fortunate.

[https://www.economist.com/](https://www.economist.com/)

<comment><USER10> I find that Economist articles about things I don't know much about are great. But the more I know about the topic, the less I think of the article.

It isn't just the spin; sometimes you can guess whom they were talking to and whom they weren't by how wrong and they way they get something wrong.

<comment><USER11> >But the more I know about the topic, the less I think of the article.

Gell-Mann Amnesia, as Michael Crichton put it:

"Briefly stated, the Gell-Mann Amnesia effect is as follows. You open the newspaper to an article on some subject you know well. In Murray's case, physics. In mine, show business. You read the article and see the journalist has absolutely no understanding of either the facts or the issues. Often, the article is so wrong it actually presents the story backward—reversing cause and effect. I call these the "wet streets cause rain" stories. Paper's full of them.

In any case, you read with exasperation or amusement the multiple errors in a story, and then turn the page to national or international affairs, and read as if the rest of the newspaper was somehow more accurate about Palestine than the baloney you just read. You turn the page, and forget what you know."

<comment> the-pigeon And IMO it's gotta much worse since Crichton said that do to online style publishing encouraging newspapers to be even looser with fact checkers and always trying to publish things ASAP over trying to publish something that is interesting, informative and/or factually corrective.

<comment><USER12> Some of it is rush to publish. But it's also that most readers here and elsewhere won't pay for subscriptions and will also do their best to avoid even the mediocre monetization provided by digital advertising. It's hard to support investigative reporting and fact checkers.

<comment><USER13> _It 's hard to support investigative reporting and fact checkers._

When the bad drives out the good, it's no surprise that no one wants to pay for the bad.

<comment><USER12> I think you have cause and effect reversed.

<comment><USER13> And I think you do. Where does that leave us?

The fact is, nobody has offered me access to a news source that covers all topics of possible interest in a manner that's free from overt biases (or poorly-hidden ones) and intelligence-insulting "both sides" fallacies. Bloomberg certainly doesn't qualify.

If such a service is ever offered, I don't expect it to be cheap, much less free... but rest assured I'll listen to their pitch. I'm sure I'm not the only potential customer for a high-end premium news product that I can actually trust.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER14> Like when they made up a story about China infiltrating servers of US companies with a nano chip that is not even technically feasible to produce and they simply ignore everyone when they were called out on their bs?

<comment><USER15> Why do you say it's technically unfeasible? The articles I saw "debunking" Bloomberg are pretty weak on their arguments. Even if Bloomberg got some things wrong, a tiny chip that subverts motherboard firmware to phone home for instructions is possible in something rice sized, for a sophisticated state actor. Network stacks already exist in firmware. You'd need to inject maybe 4KB of instructions somewhere, but I can't imagine it'd be many orders of magnitude more than that to bootstrap such a process.

The suspicious silent non-retraction raises a red flag for me, that there may have been some kind of intervention to stop their reporting on the topic.

<comment><USER14> [https://www.servethehome.com/investigating-implausible- bloom...](https://www.servethehome.com/investigating-implausible-bloomberg- supermicro-stories/)

This is a good explanation. This article is weird because it's paginated. Make sure to use the paginator below the body to read it fully.

There are many good arguments in that article but the simplest one is that there's simply no modern lithography methods to produce a chip of that size with processing power, signaling interfaces and networking, which are all required to create a trojan ship like the one described by Bloomberg. Additionally you need to provide power to this hypothetical nano-chip so you need more components like capacitors which of course is never mentioned in the Bloomberg article.

<comment><USER15> The chip doesn't need networking, it needs to infect existing firmware with networking. The motherboard/nic firmwares already have that. Nor would it necessarily be limited to the IPMI side nic as they imply. Steganography could be used to get through firewalls on net facing NICs. The part about "most sensitive code" wrongly assumes that means on storage devices and not motherboard firmware.

As for the size, there are no commercial lithography methods with that capability, perhaps. It'd be possible to put significant capacitance and logic in a very tiny package with advanced lithographic techniques, say like gates printed into layers of a small cap? Yeah I'm getting really out there, but to say there's nothing so interesting in the highly compartmentalized world of spy tech is to make a claim in ignorance, naturally. Unless you're in a position to say precisely what technology they have, in which case, please contact me privately, since I'm curious. ;)

</comment></comment></comment></comment><comment><USER16> A lot of good writing advice in this memo:

The key person to think about is the reader.

People generally read only one screen and SELDOM read more than two screens. (A screen typically is around 300 words.)

A long story on a complicated topic can save readers time if it replaces the need to read a lot of short ones.

Readers either want to have a quick piece of information or something that justifies the longer read.

A good rule of thumb is that stories should either be shorter than 400 words or longer than 900.

Taking 700 words or 800 words to make a single point will just annoy readers.

Keep it short. Think of the reader.

<comment><USER17> And, if it's going to be 900 words, then in the first 400, you'd better make it clear that you've got 900 words that are actually worth my time to read. You make it clear, not by _telling_ me that you've got something relevant to say, but by _demonstrating_ it.

</comment></comment><comment><USER18> This is more evidence the news media is self destructing.

"Enterprise stories" are where reporters take the time to learn something rather than just rewrite a press release or someone else's reporting. This type of reporting has been under pressure for years because it's expensive and media budgets are very tight. This editor-in-chief is saying the clicks don't justify the expense.

The story of the destruction of the media is well known but some of the details are underappreciated:

* Individual articles are now the fundamental unit. They are promoted on social media then carefully tracked and evaluated. A hot story get orders of magnitude more clicks/revenue so they focus on trying to produce that an ignore everything else. This narrows the scope tremendously.

* Reporting is no longer a profession but more like a calling similar to the arts. The demands are too high and the pay is too low. It takes sustained outside support (rich family, spouse, sponsor) for most reporters to make it today. Many reporters have strong ideological motivations which substitute for pay but can compromise reporting.

For the reader the bottom line is the news media is no longer the neutral source of information we used to think it was. First it is now highly biased to provoke a response, usually emotional and often just to the headline (clickbait), at this point the job is done, the ad is sold. Second the people writing and editing the stories have strong beliefs coloring their selection and content.

The result is the article contains biased, incomplete and inaccurate information. And once you let that bad information into your head it is very hard to unlearn it. You often know less after reading a news article these days!

...

Fascinating developments. Matt Taibbi has done some good reporting on this but it is typically covered very superficially by media critics. There are a few books I have yet to read but pointers to thoughtful analysis would be appreciated. This is a complex and still evolving issue.

</comment><comment><USER19> Part of the problem is Google - their algorithms reward longer keyword-laden content.

<comment><USER20> How many people hit up google search for news? Doesn't most news come from social media feeds these days?

<comment><USER21> There are a lot of people who don't use social media for news. Besides, sometimes folks want to educate themselves about a recent news subject that their social media feed hasn't surfaced for them so they'll search for additional information... often via Google.

</comment></comment></comment><comment><USER22> >enterprise stories

What is an enterprise story?

<comment><USER23> I didn't know either so looked it up: 'Enterprise journalism is reporting that is not generated by news or a press release, but rather generated by a reporter or news organization based on developed sources.'

That makes sense because he was in the memo balancing the development of sources (which can lead to enterprise stories) against the investment of writing ones that don't seem to be panning out well.

</comment></comment><comment><USER24> Which is why publishing a misleading headline followed by a misleading first paragraph, and burying the facts in the middle or bottom of the article is such a common practice. Journalists know only a small fraction of the readers will read the whole thing and it is one of the many ways to lie without lying.

</comment><comment><USER25> "'Strictly speaking ... readers aren't what they used to be ... so being a writer isn't what it used to be.' J.F. Powers" [1] pg100

"We are all suckers for statements about culture - which is not surprising when culture at first glance seems so balefully homogenous, but upon closer inspection, is so unappealingly atomized. A new angle is invariably more charismatic, more assimilable, handier in every way than the work which presumably springs from it." [1] pg20

I can't lay my hands on the exact quote but in [1] the author makes an point in the context of inflation (of ideas, and everything American): when no idea is worth a anything the only thing to do in this environment is come up with an even more seriously hyped idea I presume to sooth that gnawing sense of emptiness. This feedback loop ensures each idea is inflated keeping the inflation of ideas going and thus cheapening each idea. One unintended result in my view is paranoia, alienation, conspiracy that comes from atomization which we see in spades nowadays. This also has strong connections to another HN post in the top 50 stories on creative management.

Way underneath the original article is something far deeper than I think [1] sunk his teeth into way back in 1984. The BBG editor is struggling with how to deal with the reader who deals with zillions of possible stories and how BBG will add value for time the reader will spend. The editor's stance is but only the highest ceiling on a much deeper problem. Gents, the reader has changed. And too much of today's culture coddles him (us, me) as an anxiety ridden middle-class person trying to fight the good fight. Well, I am not so generous. A lot of readers are lazy. A lot of readers want meaning handed to them because getting experience and ideas are becoming separate islands. In Reddit Pro Life Tips format: 99.9% of what you need to know you're gonna have to learn yourself.

I close with a quote from the forward in [1]:

"'No longer is it, 'When I hear the word Culture, I reach for my revolver.' We are permitted instead, 'Culture sits so well in my pock that whenever I hear the world "thought" I smile' Phillip Sollers" [1]

[1] Salmagundi "The Post-Modern Aura" Charles Newman No.63-64 Spring-Summer 1984

</comment><comment><USER26> I applaud this note.

I wouldn't be surprised if regular newspapers have bullshit metrics that lower the quality:

\- Words per article

\- Number of clicks

\- Articles posted

It's the equivalent of measuring lines of code and transforming agile points to man-days.

</comment><comment><USER27> This has been our working hypothesis; we're building tools for newsrooms to syndicate the piecemeal updates of breaking stories throughout the day, for people who dont want to commit to long articles or videos.

[https://blog.nillium.com/what-can-napster-teach-local- news/](https://blog.nillium.com/what-can-napster-teach-local-news/)

</comment><comment><USER28> Good and concrete advice from the chief editor:

"A good rule of thumb is that stories should either be shorter than 400 words or longer than 900. You either have a simple news story or a single observation (in which case go short) or a yarn or a chance to explain something very complicated (in which case go long"

</comment><comment><USER29> In my opinion, all of journalism has become too mediocre as it seeks clicks, not readers.

</comment><comment><USER30> His comment about respecting and saving readers' time, that was one of the smartest things I've read about journalism. If it doesn't do that, it's not worth writing or reading.

</comment><comment><USER31> Ulysses journalism, [https://news.ycombinator.com/item?id=23780937](https://news.ycombinator.com/item?id=23780937)

</comment><comment><USER32> Short, sweet, and to the point has always been Bloomberg's editorial policy. I'm surprised he had to underline it to the staffers this way.

</comment><comment><USER33> Part of Bloomberg's business model is news-as-advertising; "This company developed this new therapy, find out more". I _think_ that's what the editor is referring to as "enterprise stories".

He's basically saying - listen, when a company is paying for a news article, don't let them stuff the piece or bury the lede. Get their key message down and move on, our readers skim the article for the beef anyways so you're just wasting their time by adding filler.

<comment><USER34> I think it is the other way around. The stories you are implying are paid are from press releases, though they aren't paid to run them. "Enterprise" are stories that _don 't_ come from PR, they are stories where enterprising journalists have researched and developed a story.

That is why he says:

> Before you embark on a piece of _enterprise_ , ask yourself whether it's > really going to be worth the investment, And if an idea doesn't turn out as > envisaged, be prepared to spike it and move on. A week or two spend on > source-building, without any story published, is often a much more valuable > use of our reporters' time.

[https://en.wikipedia.org/wiki/Enterprise_journalism](https://en.wikipedia.org/wiki/Enterprise_journalism)

</comment></comment><comment><USER35> This is not good for my ASD, not good at all.

ASD = Attention Surplus Disorder

I seem to be the only one here that likes Bloomberg, but then again I work in finance.

</comment><comment><USER36> I am still pissed about their story on Elemental Technologies.

</comment><comment><USER37> I unsubscribed from Bloomberg. Their articles are only relevant for finance professionals. The FT has things like personal finance and general news too - although both are of questionable political neutrality.

</comment><comment><USER38> Oh, are they finally apologizing (or providing proof for) their story The Big Hack about chips the size of a grain of rice China puts in computers made by Dell and Apple and others?

No? Not a word about it?

It's almost like they're continuing to pretend that their giant journalistic screwup doesn't exist.

Don't care. 'Are articles are too long'. How about yours articles are untrustworthy?

<comment><USER39> Some bloggers (well gruber at least) still bring this up any time they newly cite Bloomberg. It does defy explanation that the publication has not been able to offer proof of the claims from that article or simply rescind it.

<comment><USER40> They should continue to bring it up, every time, until the story is rescinded.

<comment><USER41> Bizarre thought just hit me.

What if they are correct, and stumbled onto the same trail the FBI has, and the FBI gave them an order to not discuss it anymore due to a pending investigation with national security repercussions?

Given how BB has just walked away from this article - no rescinding, no nothing, I think it's a possibility.

<comment> paul-alkhimov sorry, but it sounds like a conspiracy theory

<comment><USER39> Because it is. It has been proposed though. I think the only way this could be true is if Tim Cook and many security folks at Apple either failed to detect the exploit, or they did and are all "in on it" and essentially lying about adherence to a core company value.

The requirement of perfect secrecy and vast involvement in a lie is what typically weakens conspiracy theories as not realistic.

<comment><USER41> Who says they are all in on it?

And media has held back articles several times due to govt request - <USER2> this one just got through.

Not saying I'm right - only saying it's _possible_.

<comment><USER39> Because it would require hardware, network and general security engineers to perform the investigation. And along with that would be a dozen aides or delegates to these professionals that would be very familiar with the investigation.

It would be obvious if the results were opposite what Cook said publicly, or if the investigation was suddenly stopped and made inconclusive.

Apple would also be counting on the US government and Bloomberg to not leak "the truth" so that Tim Cook's statement would not be revealed as a lie.

The idea offers intrigue but doesn't pass any kind of reasonable pass of consideration.

<comment><USER41> You are assuming that Apple would know. Am I missing something?

<comment><USER39> I think in your idea, the exploit is real and known by LE and Bloomberg. However, Apple was not able to find this out, even though it was real. Is that the case? If so, it would suggest the FBI is allowing Apple to unknowingly use compromised systems?

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER42> The memo is 341 words.

<comment><USER43> Well within the short bucket that he describes.</comment></comment>