6 ms·

The founders had a reputation for being dickish. At some point they got into trouble for dubious SEO tactics that got them delisted from the Google index. More

by bambax 5y ago

The founders had a reputation for being dickish. At some point they got into trouble for dubious SEO tactics that got them delisted from the Google index. More controversially, they were able to unfuck themselves by reaching out to Google executives, while so many other companies are at the mercy of Google with no recourse.

DeBraid 5y ago
The drama with Google has to be mentioned as major part of their company history. They also had a famous fight with heroku https://genius.com/James-somers-herokus-ugly-secret-annotated https://genius.com/James-somers-herokus-ugly-secret-annotate...
- jayzalowitz 5y ago
  If you are capable of making this post, you are capable of self hosting rails on something closer to the metal.
- nomilk 5y ago
  Genius's investigation and analysis of Heroku's load balancing claims vs their actual practices was anything but "dickish", and it wasn't a "fight". They produced an intelligent, thorough, and fair exposè of poor engineering practices by Heroku which were otherwise not documented (or worse, misleadingly documented), and which also benefited Heroku financially, since users would have to purchase many more dynos to get the expected performance - up to 50 times more if I recall correctly. Genius didn't have to share any of their analysis. They could have simply shown it to Heroku and probably received a bunch of "hush" benefits to forget about the whole thing. The fact they bothered to polish it and open source it allowed others to benefit from their work and meant that even 8 years' later, someone like me can better plan hosting requirements and avoid falling into the trap they did. Yes, Heroku's load balancing works the same way to this day, resulting in much higher costs to medium-large apps as well as huge degradations to end user experience as some users will randomly be routed to dynos with long queues despite others being completely idle! This is a huge waste of energy and bad for the environment too. As a heavy Heroku user, I'm incredibly grateful for Genius's work on this issue!
  - glenngillen 5y ago
    That’s one interpretation of the events, motivations, and hypothetical alternative situations. Or it’s simply that Heroku didn’t provide customers great visibility into a the issue at hand, that the best-in-class at the time 3rd party add-on that gave that visibility was misleading, and that architectural changes required to support a broader set of languages in a more distributed fashion introduced a change in behaviour that was not documented. The engineering best practice continues to be the same, which is why it is unchanged 8 years later: push long-running requests into an async flow. It’s both more scalable and more durable.
    - nomilk 5y ago
      It's a problem for any application on Heroku that uses more than a single web dyno (i.e. any software other than tiny applications), and certainly not limited to applications with long-running requests. Consider Genius's checkout analogy: busy markets are efficient because customers sort themselves into the shortest queues. If customers were randomly allocated queues, some customers will wait in lengthy queues while others queues remain empty! Critically, the same logic holds whether customers have lots of items (long-running requests), or very few items - one is slightly worse, but customers are still waiting unnecessarily while other queues are free to be used (but aren't). So it's a problem even for applications with no long-running requests. Suppose a user's request falls in a queue with 10 users being served first, while other queues are idle, also assume requests are reasonably fast - 3000ms - then you still have to wait 33 seconds (!!) for the "3000ms" request to be served (!!) - I think that will error because heroku times out requests at 30000ms. This is a disaster for UX. Someone made a simulation to show how incredibly wasteful it is: https://gist.github.com/toddwschneider/4947326 https://gist.github.com/toddwschneider/4947326 Note that while it would be great for it to be improved, I in no way demand/expect that, I just don't think it's fair that Genius aren't given credit for their analysis - analysis that Heroku ought to have provided. It shouldn't have been Genius or other customers to expose that Heroku had misguided them, even if it happened accidentally and without intent.
      - glenngillen 5y ago
WORMS_EAT_WORMS 5y ago
I love the idea of "annotating everything" / the web. A browser extension or something would liberate people from these walled social media gardens of interacting. Just not attractive and a hard sell. I remember seeing a cringy interview of the founders. Candidly, I'm not surprised they couldn't convert their idea and make it happen with something bigger. Who knows though they did raise the cash. I still think there is room here though.
- bambax 5y ago
  Google created Sidewiki [0] in 2009 and killed it two years later. It was based on a browser extension. There have been many other initiatives, some listed here [1]; Wikalong was interesting but riddled with spam. Maybe a personal system (not shared) would help prevent content abuse? But then it would probably offer too little value to really take off. [0] https://en.wikipedia.org/wiki/Google_Sidewiki https://en.wikipedia.org/wiki/Google_Sidewiki [1] https://en.wikipedia.org/wiki/Web_annotation https://en.wikipedia.org/wiki/Web_annotation
- cxr 5y ago
  Hypothesis is going strong. They have smart people working on it, it's fully open source with open APIs and data available over anonymous RSS, the culture is nothing like rap/bro culture, and the founder is independently wealthy from winning the startup lottery in a past life and seems to be running the thing as a passion project no matter how much it makes. (Their main commercial play right now is selling higher ed. on the idea of using Hypothes.is for scholarly criticism.) See "Notes for an Annotation SDK" from a couple weeks ago <https://blog.jonudell.net/2021/09/03/notes-for-an-annotation-sdk/ https://blog.jonudell.net/2021/09/03/notes-for-an-annotation...>

by bambax 5y ago

DeBraid 5y ago

The drama with Google has to be mentioned as major part of their company history. They also had a famous fight with heroku https://genius.com/James-somers-herokus-ugly-secret-annotated https://genius.com/James-somers-herokus-ugly-secret-annotate...

jayzalowitz 5y ago
If you are capable of making this post, you are capable of self hosting rails on something closer to the metal.
nomilk 5y ago
Genius's investigation and analysis of Heroku's load balancing claims vs their actual practices was anything but "dickish", and it wasn't a "fight". They produced an intelligent, thorough, and fair exposè of poor engineering practices by Heroku which were otherwise not documented (or worse, misleadingly documented), and which also benefited Heroku financially, since users would have to purchase many more dynos to get the expected performance - up to 50 times more if I recall correctly. Genius didn't have to share any of their analysis. They could have simply shown it to Heroku and probably received a bunch of "hush" benefits to forget about the whole thing. The fact they bothered to polish it and open source it allowed others to benefit from their work and meant that even 8 years' later, someone like me can better plan hosting requirements and avoid falling into the trap they did. Yes, Heroku's load balancing works the same way to this day, resulting in much higher costs to medium-large apps as well as huge degradations to end user experience as some users will randomly be routed to dynos with long queues despite others being completely idle! This is a huge waste of energy and bad for the environment too. As a heavy Heroku user, I'm incredibly grateful for Genius's work on this issue!
- glenngillen 5y ago
  That’s one interpretation of the events, motivations, and hypothetical alternative situations. Or it’s simply that Heroku didn’t provide customers great visibility into a the issue at hand, that the best-in-class at the time 3rd party add-on that gave that visibility was misleading, and that architectural changes required to support a broader set of languages in a more distributed fashion introduced a change in behaviour that was not documented. The engineering best practice continues to be the same, which is why it is unchanged 8 years later: push long-running requests into an async flow. It’s both more scalable and more durable.
  - nomilk 5y ago
    It's a problem for any application on Heroku that uses more than a single web dyno (i.e. any software other than tiny applications), and certainly not limited to applications with long-running requests. Consider Genius's checkout analogy: busy markets are efficient because customers sort themselves into the shortest queues. If customers were randomly allocated queues, some customers will wait in lengthy queues while others queues remain empty! Critically, the same logic holds whether customers have lots of items (long-running requests), or very few items - one is slightly worse, but customers are still waiting unnecessarily while other queues are free to be used (but aren't). So it's a problem even for applications with no long-running requests. Suppose a user's request falls in a queue with 10 users being served first, while other queues are idle, also assume requests are reasonably fast - 3000ms - then you still have to wait 33 seconds (!!) for the "3000ms" request to be served (!!) - I think that will error because heroku times out requests at 30000ms. This is a disaster for UX. Someone made a simulation to show how incredibly wasteful it is: https://gist.github.com/toddwschneider/4947326 https://gist.github.com/toddwschneider/4947326 Note that while it would be great for it to be improved, I in no way demand/expect that, I just don't think it's fair that Genius aren't given credit for their analysis - analysis that Heroku ought to have provided. It shouldn't have been Genius or other customers to expose that Heroku had misguided them, even if it happened accidentally and without intent.
    - glenngillen 5y ago

WORMS_EAT_WORMS 5y ago

I love the idea of "annotating everything" / the web. A browser extension or something would liberate people from these walled social media gardens of interacting. Just not attractive and a hard sell. I remember seeing a cringy interview of the founders. Candidly, I'm not surprised they couldn't convert their idea and make it happen with something bigger. Who knows though they did raise the cash. I still think there is room here though.

bambax 5y ago
Google created Sidewiki [0] in 2009 and killed it two years later. It was based on a browser extension. There have been many other initiatives, some listed here [1]; Wikalong was interesting but riddled with spam. Maybe a personal system (not shared) would help prevent content abuse? But then it would probably offer too little value to really take off. [0] https://en.wikipedia.org/wiki/Google_Sidewiki https://en.wikipedia.org/wiki/Google_Sidewiki [1] https://en.wikipedia.org/wiki/Web_annotation https://en.wikipedia.org/wiki/Web_annotation
cxr 5y ago
Hypothesis is going strong. They have smart people working on it, it's fully open source with open APIs and data available over anonymous RSS, the culture is nothing like rap/bro culture, and the founder is independently wealthy from winning the startup lottery in a past life and seems to be running the thing as a passion project no matter how much it makes. (Their main commercial play right now is selling higher ed. on the idea of using Hypothes.is for scholarly criticism.) See "Notes for an Annotation SDK" from a couple weeks ago <https://blog.jonudell.net/2021/09/03/notes-for-an-annotation-sdk/ https://blog.jonudell.net/2021/09/03/notes-for-an-annotation...>