Because of that stake, they want an "exit" in some form, and the drive to that exit will pave the road to user-hostile software and make it the path of least resistance.
Because of that stake, they want an "exit" in some form, and the drive to that exit will pave the road to user-hostile software and make it the path of least resistance.
That being said, dev tools is one of the sectors they have stopped funding, seemingly.
I am bootstrapping. I own 100% of the company.
I am just different; I don't want gold. I want:
* Sufficient money for my needs and no more.
* To change the industry towards professional standards. [1] [2]
[1]: https://gavinhoward.com/2023/11/how-to-fund-foss-save-it-fro...
[2]: https://gavinhoward.com/2022/10/we-must-professionalize-prog...
My wallet unfortunately does not.
Bootstrapping is hard, and I know that I am lucky to be able to...thus far.
If the world would still be net better off with the VC-backed software, and it wouldn't get made any other way, I don't think it would be immoral to take it, so long as effort is made to follow the harder path.
One note: technically my software isn't quite Open Source; it's source available. [0]
I will have my first release in less than two months, hopefully. It will include a scripting language and a build system.
If the language gets interest, I'll expand it and build the standard library.
If the build system gets interest, I will expand it. The end goal is Nix for mere mortals.
If neither gets interest, I will have to move to my next idea: VCS with project management and that handles large, binary files.
Beyond that, we'll see.
I have a business website, but not yet for those projects. I will at release, including tutorials.
You can read an old commit of design docs at [1], [2], and [3].
It's just me; I want to run my business like Hwaci, the SQLite guys. That also reduces overhead and will let me provide excellent support [4] for paying clients.
[0]: https://gavinhoward.com/2023/12/is-source-available-really-t...
[1]: https://git.yzena.com/Yzena/Yc/src/branch/master/docs/yao
[2]: https://git.yzena.com/Yzena/Yc/src/branch/master/docs/rig
[3]: https://git.yzena.com/Yzena/Yc/src/branch/master/docs/yar
Though, a lot of advice given to YC companies is on how to build big companies that scale (unicorn+), so if you don't plan on doing that, you may not get very much out of the program.
I have spent years building my stack. This stack gives me extreme velocity.
For example, I built my own localization. I query the OS for the locale, but beyond that, everything is mine. This allows me to make more assumptions and move faster.
In addition, this allows me to cull tech debt aggressively. [1] After years of this, when other codebases are molasses, mine is clean and easy to extend.
In other words, I did the hard work upfront, before getting clients. I hope this will give me the ability to add the "vital few" with few resources.
[1]: https://gavinhoward.com/2023/12/code-is-not-technical-debt/
However, there are rumblings that standards and liability will be imposed on the industry.
In that case, I would be well-positioned as someone who could accept that liability for a price. Your run-of-the-mill build system created by volunteers? Not so much.
I do admit that I don't want a unicorn either, so YC wouldn't be a good fit.
This works out well because it's the global optimum. YC has much more success optimizing for helping founders than it would by trying to squeeze individual lemons.
That said, that sibling comnent suggests that YC is for potential unicorns, and I don't want that either. So YC is not for me.
Though I will say nothing wrong with unicorns per se.