glacials

I believe in your mission. The world needs a better way to fund open source development.

At first glance, your product feels unrelated to this. It seems like a Stack Overflow replacement that's worse for posterity (read: googlers) because chats are private. It also feels like a side-gig for open source developers, asking them to basically freelance to fund their open source projects, which I don't think is how that should work.

I think you'd have more luck as a platform for paid support licenses for open source software. Bootstrapping a support license program is a Big Deal for independent open source developers who don't want more administrative work. But this feels like a miss on that front. Happy to confer more.

> Minus server costs and wages, all of the money processed through Immutable Coffee will go directly back to the developers and experts answering questions for the community.

You might want to look into forming a nonprofit, as this is almost exactly what it is (minus ownership stakes). If you're a nonprofit people don't have to trust sentences like this, as it's baked into your existence.

Good point! I meant to convey free-as-in-beer; I'll fix this wording now!

Hey HN, I'm Ben Carlsson. I recently left Twitch (YC W2007) after five years and have founded an open source esports startup. In my downtime I've been trying to solve the perception issue that causes many open source authors (including myself) to be afraid of making money off their software.

Several times a year I've seen open source authors have mental breakdowns and post, more or less, "I'm giving up because of the unbelievable stress and/or lack of income, someone please take this off my plate".

As a community, it's embarrassing that such dedicated and successful authors have been driven to the edge, but on top of that every time it happens it contributes to a perception issue about open source software: "it might lead to a mental breakdown, better not".

Something is broken here. The kind-hearted are being driven away from open source. It's time to marry kind-heartedness with the free market. Open source should not mean poverty. Open source should not mean sacrificing nights and weekends with friends and family to fix bugs for large corporations for free. Working hard is one thing, but consuming your life with perceived obligations that don't put food on the table is another.

I believe dual licensing is a possible solution to this, but it hasn't taken off for two reasons:

1. Authors are afraid companies won't use their software because of the friction involved (not the $, but the internal bureaucracy) 2. Authors just want to write code, and can't be bothered to deal with licensing and payments and "customers", so just choose MIT

Dual licensing is what it sounds like -- the author chooses two licenses instead of one. The user chooses which one they want to use. Usually one is free but has restrictions (e.g. GPL), another is paid but has no such restrictions (a commercial license).

I'm trying to solve these two issues with dual licensing. I built Licenseland to take on #2, taking the extra headaches out of things like accepting payment. For now the #1 fear still remains, but I think it can be abolished with good success examples helping to set industry standards. Companies need to know that great open source software might cost some pocket change, and that letting their engineers spend that money should be a well-lubricated flow without second-guessing.

I will fall in love with you if you give me any feedback on this idea! I've been an open source developer and advocate in and out of companies (and government programs) for a decade now. Much love <3

Funny when you can get this narrow window into the team members writing vs. the ones editing!

I left my silicon valley job and am building a speedrunning analytics startup out of a side project I started 6 years ago.

https://splits.io

It depends on your backend architecture. We migrated a microservices (Go) architecture to GraphQL and it gets very complex with a lot of boilerplate. Perhaps part of that is GraphQL's and its supporting libraries' infancy, but supporting the ability to ~infinitely nest objects in a microservices architecture at scale makes every field addition feel like building a gigafactory.

On the plus side GraphQL is very simple and adaptable for frontends. It just comes at the cost of moving so much complexity to the backend.

They're different. Microservices are still stateful applications that run 24/7. They are just really small in scope.

e.g. the Friends feature on Twitch is one microservice, running in its own autoscaling group, with internal APIs used by other microservices like Whispers.

Hehe, great job on that Chris :)

Miss you too buddy! Hit me up when you're in Seattle next.

Oh, edited! Thanks Spencer :)

I worked at Twitch from 2014 to 2018. I was never on the video team, but here are some details that have changed.

Video:

- Everything is migrated from RTMP to HLS; RTMP couldn't scale across several consumer platforms

- This added massive delay (~30+s) early on, the video team has been crushing it getting this back down to the now sub-2s

- Flash is dead (now HTML5)

- F5 storms ("flash crowds") are still a concern teams design around; e.g. 900k people hitting F5 after a stream blips offline due to the venue's connection

- afaik Usher is still alive and well, in much better health today

- Most teams are on AWS now; video was the holdout for a while because they needed specialized GPUs. EDIT: "This isn't quite right; it has more to do with the tight coupling of the video system with the network (eg, all the peering stuff described in the article)" -spenczar5

- Realtime transcoding is a really interesting architecture nowadays (I am not qualified to explain it)

Web:

- No more Ruby on Rails because no good way was found to scale it organizationally; almost everything is now Go microservices back + React front

- No more Twice

- Data layer was split up to per-team; some use PostgreSQL, some DynamoDB, etc.

- Of course many more than 2 software teams now :P

- Chat went through a major scaling overhaul during/after Twitch Plays Pokemon. John Rizzo has a great talk about it here: https://www.twitch.tv/videos/92636123?t=03h13m46s

Twitch was a great place to spend 5 years at. Would do again.

It really has nothing to do with this. If the quotes you mentioned are real then I'm ashamed members of the community would speak like that towards developers. But the terminology of "destroying" a game has nothing to do with badtalking developers. This is purely about understanding a game so well that you can undermine it. See also: "tearing up the dance floor".

I build and run Splits.io, a self-analytics tool for speedrunners. They upload basically log streams and I tell them where they can get better.

These are pretty common terms in a speedrunning context and I do not believe they were meant by the author to be emotionally charged. Because speedruns often take advantage of game-breaking glitches, the extent to which the game has been literally broken is usually described with destructive terms like these. Smashing records, destroying games, obliterating levels, etc.

It makes a bit more sense if you imagine the developer's intended way to play the game being a glass bridge across a chasm, and speedrunners literally shatter the bridge and glue the pieces into a ramp that they jump a dirtbike off.

Source: I've been speedrunning for 7 years and my full-time job is in the speedrunning community

The author specifically calls out ephemerality as a feature of IRC.

If it's easy to get history people will assume everyone is reading what they're typing. This would make people feel obligated to play catch-up every time they miss some messages due to being AFK or in the zone.

By making history hard to obtain, IRC simulates real-world conversation -- you're either in the room or you're not.

Total amount fined vs total amount spent complying aren't comparable numbers. One side has orders of magnitude more organizations comprising its number than the other.

We need a median amount fined to non-complying organizations vs. median amount spent complying by complying organizations.

Similar in effect, but not in method. Turbolinks fetches pages after a click like normal, but swaps the body tag from the new page into the current page, cutting local render times.

Idempotency is not the issue, the issue is that a user might hover over the logout link, not click it, then move on to the rest of the site and find they are logged out for no reason.

The author seems to imply the smart reply buttons immediately send an email with the chosen phrase. This is incorrect. They open an email draft beginning with the chosen phrase.

There are many times I've used one of these buttons to begin a much more detailed email. Not only do they save a few keystrokes, but they help you get past that first wave of "blank canvas" writer's block.

Ben, every point I've been lucky enough to witness you argue at Twitch has alway shone this Neutral Good seed behind it. Unjustified process, user-harmful acts, and any worsening of free speech cause you to interject, never to "wait and see" forever and never to disagree without speaking up.

I honestly have become better at this skill by being nearby when you exercise it. And I believe I have spread that to others in my life in turn. I absolutely would be a different person had our desks not happen to end up across from each other through three office shuffles. And I never met Aaron, but I believe by influencing those around you in this way you've done so much more to honor him than the two big ticket items you give yourself credit for.

This is also known as key-based cache expiration, detailed by DHH here: https://signalvnoise.com/posts/3113-how-key-based-cache-expi...

You never worry about when to expire your cache entries if the key changes every time the item does. It's nice to finally see cache-busting coming out of the woods.

Super enhance!

http://www.dailymotion.com/video/x2qlmuy