I don't know you, but please don't consider yourself a loser. Ever.
There might be many reasons why you were never accepted to YC, despite applying nine times. Heck, I actually plaude your "stubbornness" / "determination", which is not common.
Don't despair. Sometimes life is hard, sometimes life has other plans for us. Perhaps there's a big success for you just around the corner.
And if not... There's nothing wrong with not being YC-backable. You are still a human being.
Hey, please don't be discouraged, for us it worked because (imho) we came to YC interview with existing paid user base growth, so it was far beyond the idea stage. And I personally applied to YC 3 times, starting from 2015:)
I think it's wrong to try to push the responsibility for other people's choices to use something or not to the person who creates that thing. And it's also very contradictory to another aspect of hacker or engineering culture which is like... someone can create a amazing free security service and then that service can be used in deplorable ways by criminals but almost nobody in this scene will admonish the creator because they realize that the creator is not responsible for how people choose to use that creation. not to mention that exact sentiments is basically universally expressed in every license that exists. so I really think it's embarrassing how such supposed criticism passes on these forums without being you know immediately dismissed as ridiculous.
It is also impractical to expect the Creator to anticipate all the use cases and potential benefits and pitfalls that people might find in those different use cases and express them.
Second it's fundamentally a violation of a boundary about choices. The people who make the choice to adopt software or not are the ones who are responsible for the technical debt or credit they allocate by making that choice.
Instead of criticizing creators for not adequately disclaiming their new products because of a hypothetical or real harm that is incurred because people choosing that, you should criticize the people selecting things for being irresponsible with the projects they are responsible for.
If your evaluation of a project is simply based on reading the readme at a superficial level then it's nobody else's fault but yours if you end up with problems with the tech that you choose.
I'm not saying you're being mean here I think this is just a misguided attempt to try to avoid technical debt but it doesn't focus on an effective way to do that. What I feel is disappointing is how this sort of criticism is often leveled at new projects as a way to dismiss or I think unfairly criticize these creations and their authors, maybe as form of "concern trolling." if I understand that term correctly.
Like, "don't use this new project in production" is sort of a tautology of "be careful about any tech that you choose that it's suitable for your use case", which is pretty obvious and I think low value thing to say, but it's often said about new projects in a way that suggests "this project is terrible and the author is bad for suggesting that people even think about using this". which I think is very toxic to a culture of creation, invention and tinkering and it's disrespectful of people who put in the effort to make something. it also encourages something which I think is harmful which is the need to think "I need to make this project perfect and bulletproof before I even think of releasing it" which I think means there's a lot of projects that could have benefited if they were appreciated at the small flame level, but maybe people are discouraged from putting them out there because of this sort of misused criticism.
even though I'm not really a fan of his I think Paul Graham said something about this point regarding startups that's like a startup is like an idea that's just being born and it's very fragile so you have to kind of protect it but it can grow into something really amazing.
That sounds like it comes from some specific experience you had... but it's pretty uncalled for to apply it so confidently to someone you don't know. Don't be mean, right?
Actually, another view is that there's nothing wrong with tinkering and DIY. Perl, JS, Redis all came from people hacking their own solutions (as far as I know).
Also, many big software orgs build extensive internal tools themselves.
Plus, making your own stuff is a lot of fun. You should try it sometime (if you haven't already) :)
Being ignorant didn't make you a prima donna tho, as above says.
Also, they have to have some clue about the domain, because the domain is their own problem and they're writing a solution for it. So I don't think we can really just someone as not having any clue about their own engineering challenges.... especially if they're working solutions to them....
Antirez said literally he didn't know about existing solutions when he went to write redis, and he and redis are awesome. nothing bad about that
but I get your point about bad solutions are bad but that's sort of a tautology, doesn't add much value, and who are we to judge someone else's solutions are bad we don't know everything about their use case.
Again... even if we can say that you choosing someone else's technology for your problem is not a good solution we just can't criticize the author because it's your responsibility what you choose. so I just don't think it's valid to criticize the author
> they have to have some clue about the domain, because the domain is their own problem
They can be lifelong experts on their problem, yet have no clue about writing a database engine and low-level programming in general.
> Antirez said literally he didn't know about existing solutions when he went to write redis
Nobody is born with knowledge. The difference is that Antirez studied previous solutions, studied how to do it, and then applied that knowledge right.
Instead, that person did the equivalent of building a bridge disregarding everything humans learnt about it since the Roman empire. It will not be a surprise if the bridge ends up collapsing.
You'd expect her to be well informed... she's a Colonel with 3400 hours in high performance jets.
I didn't know there were women pilots and colonels flying these craft. The only clear idea about high profile women in the services was them being accepted into marines.
a distributed way to map and collect the data structure on the web crowdsourced from a community of people not only passionate about mapping out the structure of app HTML and how it corresponds to data types, but also people who want to collect and use that data.
the data can be used for anything from competition and pricing analysis, to dashboards, to creating automatic RSS feeds of anything.
it just seems that being able to unlock the latent value of all of the information, the structured information on the web, which is presented only in a semi-structured form but which, with the addition of human labor, could be made so it's machine usable could unlock so much value.
but I've been pitching VCS and y combinator on this idea for the last six or seven years and not so much as a peep of interest so it seems that this idea doesn't possess a way to create a lot of money but I do believe it's very valuable.
good question. but I think the answer is obvious when you consider the different risks enormous groups and small groups face from disputes.
for small groups nearly every dispute could pose existential risk, but for enormous groups very few disputes pose existential risk. then in the conflict side, enormous groups have MAD, where conflict itself carries existential risk. small groups of course can also be wiped out by conflict (even if they don't possess a bureaucratic mechanism to ensure that,) but the risk side of the calculation is heavier for them I think.
and enormous groups still engage in conflict with each other although it happens indirectly via proxy wars.
also paradoxically the larger the group becomes the more its interests, or "meta interests" (such as favoring stability and security), tend to align with its competitors but for small groups it's almost like every group for itself. but I believe that the calculation can tend towards cooperation being more beneficial the larger group gets. but I think this factor only applies when groups become very very large.
also there's some sort of entropy argument as in large groups cultivate more structure, organization and order and therefore it would take more energy to dismantle them so they're more stable. which not only makes them harder to dismantle but also gives them more to lose if they were to decide to tear everything down and build it up again.
I think you have posited interesting ideas about the decisions that small and large groups make about when to engage in conflicts and how to ensure long term survival. I am not sure how true they are in reality, but I can certainly see where you are coming from.
If I put myself into that situation for a moment, as the leader of a small armed group, I can see two options at first. The first option is to go into hiding and potentially die of resource starvation if I am unable to cultivate the things needed to survive on my own (or be killed by outside attackers). The second is to grow bigger and bigger by forcibly and preemptively taking over the other small groups so I can secure my borders so to speak, but going on the offensive can also lead to premature death as well.
As a result I think some hybrid approach is needed, where one goes into hiding in a land so far away and inhospitable that nobody wants to attack, thus there's nobody to fight.
What if something about the electrical signal attracts growth in certain direction, toward other signals firing at the same time?
Or what if some neuron pairs that are not yet connected share quantum entangled structures, that if activated simultaneously ... but still how does direction occur?
What if neurons emit light, that's why you can stimulate them with light...and what if they can somehow detect the faint light from other neurons and get the direction the light comes from, and grow towards that?
Thank you. so you work in this area? what do you think about the software available for your research? Could it be better or does software not play so much of a role?
Haven't seen your tool in particular, thanks for the link, I'll check it out. I only used
https://github.com/pirate/ArchiveBox before, but haven't set up an automatic archival pipeline (yet)!
Also, integrating with local web archives is on my Promnesia todolist! I expect them to be very useful for indirect history retrieval, e.g. "I haven't visited that page, but it's within one link". Having local web archives makes it possible to implement such functionality in efficient way.
You have a really interesting way of thinking about all this stuff and have synthesized alot of different ideas, that I believe point to a future for the web. very cool to come across your work. Do you have a blog?
I think because it's based on the DevTools protocol which is only partly supported (I think) in Moz.
Although you're right with enough work someone could engineer a way to achieve the same, even without DevTools protocol. I picked the protocol because it made it easy to achieve.
I think in future FF plans to support DevTools, or the standardised version which I think is called WebDriver protocol or something.
Good luck with your business. it's really awesome you were able to get through to them that this is a huge business