We were in the same YC batch (S'10), and the founders were all kind, smart people. They were also determined and hard-working: I believe they'd been rejected by YC three times before getting in.
Many people have asked over the years what types of things people do at RC. It's a surprisingly hard question to answer, because the work people do here is varied and diverse, from contributing to OSS projects to silly hacks to algorithmically generated art.
We built Joy of Computing to answer this question. It's a daily link aggregation site which posts one piece of work done by a current Recurser or an alum every day.
As far as I know Dropbox has no connection to Zulip now. Zulip was initially started as a company, which was acquired by Dropbox several years ago. Dropbox open sourced the code, and Tim (one of the Zulip cofounders) later left Dropbox to focus on running Zulip as an open source project.
We (the Recurse Center) have been using Zulip since early 2013, and it is the core of our online community. Zulip is excellent both for small teams (we use it for our team of 7) and big groups - we also run a realm with over 1,000 users posting 10s of thousands of messages monthly. I can't recommend it highly enough.
It's definitely possible to run a Zulip server with essentially no downtime. E.g. the main zulipchat.com service has had approximately 10 user-facing outages with a median duration of 5-10 minutes over the last 5 years (there was one while we still only had a few hundred users that lasted overnight), most of them in the middle of the night. Happy to talk more about this for anyone curious; there are some fun stories (like migrating from MySQL to Postgres as our primary database technology with <30 minutes of downtime early in its development).
We don't have a public uptime SLA for zulipchat.com uptime yet, but we're happy to make them for individual customers (and I suppose we should add one).
If you're self-hosting, our commercial support offerings will help you setup your servers in a way that achieves your uptime goals; because Zulip is so stable, usually folks just go with a hot spare (our enterprise customers generally only report downtime related to server upgrades, which is usually avoidable).
We don't run our own instance; we're hosted by zulipchat.com. Perfect uptime isn't a priority for us, so I don't know what (if any) availability they promise. But we've had almost no downtime over the past five years, and we've certainly had less than the public Slack outages I've seen folks talking about on Twitter :)
It's very inaccurate for my batch (S10) at least, for which I know of about twice as many exits as are listed.
And as others have mentioned, the bigger challenge is that "exits" aren't a good metric for either gauging YC's success or for making founders rich. The companies that have "failed" to convert (i.e., exit) from S10 include Stripe, PagerDuty, and Docker.
Sure, but that error rate is probably relatively consistent. Probably exits aren't listed for earlier years either. Unless everyone is getting more secretive about exits, which is interesting in itself.
Anyways, maybe someone from YC will comment. They know the truth and it's a worthwhile figure to publish.
It is probably not that exits are more secret and more that since YC has scaled up the number of entrants, so the number of exits that people care to publisize becomes a smaller and smaller percent of the total number of members in a batch.
YC continues to support my company nearly seven years after our batch, even though we're still tiny and have no plans to exit (and thus will likely never give them any financial return).
Not sure what more you can do when the business isn't going well. 2+ years of maintenance, open sourcing, 2 months notice, data export, no additional billings.
What was “the product”? They got a ton of attention initially but it really felt like that was squandered by the poorly defined message about what you were paying for — especially when many proponents reacted to early “it's like Twitter but open” stories by saying they were wrong and it was something else entirely, possibly only for developers.
The primary memory which I have of that era are people not wanting to pay for something which wasn't clearly useful, shrugging, and going back to Twitter where most other people were. By the time app.net finally launched the free tier the self-inflicted damage was already fatal.
The moment they allowed free accounts was the start of the end. The spam and the noise came. All the things we were trying to avoid. But they just wanted beefier numbers to throw around.
I developed quite a few apps on the platform and made a few thousand in the process. It more than paid the fees back and was totally worth it.
I continue to be at least somewhat optimistic that non ad-supported models are worth trying. It seems like Patreon is doing really well and is perhaps something we can all learn from.
Yeah, for app.net I think it was more chicken and egg that killed you than paid per se. Pay presents an especially difficult chicken and egg problem because not only do you have to get people to part with their time to sign up you have to ask them to pay for what may potentially be no value provided.
I remember trying to explain why it wasn't a stupid idea to people way back when it launched on HN, and had kind of assumed that it'd died years ago.
----
Hypothesis: If you can find a way to provide value while you build up the network, the product would do better.
Second hypothesis: If you can find a way to acquire valuable users with a low-effort funnel and 'leech' users with a paid funnel that would also make the product perform better.
Taking these as assumptions for a moment, this would imply a natural advantage for federated networks if they provide interoperability between different services that have value on their own without network effects.
I followed what you were doing at app.net with great interest when it launched. We were also building an app platform, but with a very different focus. https://qbix.com/platform . All our business models are NOT ad supported. Ads are "begging" the user to spend their time and maybe spend money. There are many ways to make money if you make apps for local communities.
We sort of took the tortoise approach to development, and this seems to have helped solve the chicken and egg problem with the userbase.
I'd be very curious to hear the kind of questions this raises about the app economy. Do you mean mobile apps? All software?
App.net was neither. It tried to be a platform for too many things for not enough people. So I can't see how its failure reflects on the economy and not just a bad idea.
Also it's pretty awesome to see a shutdown accompanied with an open sourcing. If every startup did this, we'd have a ton more open source code out there to play with.
I'm a cofounder of a YC company. This June will be the sixth anniversary of when we did YC, and our company isn't exactly a billion-dollar darling (to put it mildly). Nor do we have any interest in going public or being acquired, so the odds of YC seeing any sort of financial return from us are slim.
Nevertheless, we commonly get email responses from YC partners (including Sam) inside of five minutes, and I've met and gotten helpful advice when we needed help from six partners (including Sam) in just the past year or so.
YC doesn't only help the huge successes: They also do a tremendous amount to help tiny companies, and even if they're still tiny many years after YC.
To be fair, Hacker School / Recurse Center is a considerably large brand name and is doing imperative work in the programming education sector.
Regardless your anecdote does parallel other YC companies' in that a Brian Chesky email is tantamount to a first year YC founder's or as you mentioned a founder from batches over half a decade old.
Sorry to hear our previous answer wasn't clear. Yes, residencies are an invite-only thing, however, everyone is welcome to apply to attend RC :)
We recently updated our User's Manual (see: https://www.recurse.com/manual#sec-residents) with more info about residents, including what we look for and that they're selected via invitation (typically after being suggested by current members of our community).
We were in the same YC batch (S'10), and the founders were all kind, smart people. They were also determined and hard-working: I believe they'd been rejected by YC three times before getting in.