The original complaint was about paying taxes when you are granted options, which is not a thing.
The fact that one would receive significantly less salary compensation vs FAANG has nothing to do with taxes or startups really, it's just plain and bad decision making. If one is going to get a salary cut, one should make a rough analysis valuing the options/stocks adjusted for the few scenarios and compare.
Plus, 95%+ of Engineers (senior or not) don't get into FAANG, so the generalization is not appropriate.
In practice, most people assume the value the equity and options to zero, and always assume it is cherry on top. If you value the stock at zero and get a massive pay cut, then it's just a bad decision.
No need to throw the baby out with the bath water.
One of the key issue is that most people do not know or understand how the equity piece works, leaving the door opened for abuse.
It doesn't have to be complicated. Two things to check if one is granted equity or options:
- What is the rough value of the stock when granted? 409A is the tool for that although it is usually quite conservative, which is good for the recipient.
- Do I have the same class of stock as management/founders: ensures no funny business around dilution.
The main issue with option is the lack of liquidity.
One may have to put down quite a bit of cash down in order to exercise, and that is a problem, even if in practice, it is usually good value for the option holder.
But most people either 1) do not have a lot of cash on hand, or 2) do not have the appetite to tie their hard-earned cash to anything illiquid-that-maybe-could-go-to-zero.
You only be hit by a tax bill if you chose to exercise the option, which only make sense if the stock is worth more than the strike. If you are "given" something that is worth more than $1, the IRS will want a piece of it.
If you worked at a startup (not a small business), the most likely outcomes after 4 years is either 1) Company went bust, 2) Company grew.
The option protects you from the not having to pay anything if scenario #1 happens. If scenario #2 happens, then you should be happy: you have an option to pay X for something that is usually worth multiples of X after 4 years.
I actually think the IRS is being nice not to tax the at-the-money option grant. They essentially assume zero time value, which would be quite high for a startup given the high volatility and the potentially long term for the option.
Not sure where you live, but in the US, options are typically granted with a strike price equal to the latest 409A valuation, which makes the grant neutral from a tax standpoint.
I don't see a world where you have to pay lots of taxes for worthless options, unless someone really screwed-up (i.e. messed up the 409 Safe Harbor election etc...)
Now... if you exercise the option, that is a different story. At least in theory you would only exercise if things went well and the stock went up vs the strike, which makes sense why one would have to pay taxes then.
This goes against the HN trope that "you don't need Kubernetes unless you are Google-size".
It turns out Kubernetes is actually perfect for small teams as it solves many hard operational issues, allowing you to focus on the important part of the stack: the application.
The key is to stick to a simple setup (try not to mess with networking config) and use a managed offering such as GKE. We may need a Kubernetes, The Good Parts guide.
Developing a tech startup is hard, and 90% of the costs are usually in labor (real or opportunity cost if you are working "for free").
Trying to save a few bucks each month when you are paying engineers $10K+ per month just doesn't make sense. Many engineers are also not good at thinking in "analog" (vs digital) and obsess on things that just impact the wrong thing.
Those comments about people using a couple $100s for monthly SaaS service a few months ago baffled me. The real question is: do those multiply/improve the output of your most scarce resource?
Saving a couple $1000s per year is good all else being equal, but in the end it's creating $100,000s more that matters in business.
I do not think anybody is making the _legal_ argument that consumers of publicly available software with an associated clear LICENSE file are granted any additional rights. Open Source is much more than what you are suggesting. It's like saying all there is to soccer/football is <first degree technical definition here>.
Just like most things, there is a very important and obvious people/social dimension on top of that.
It's not entirely surprising this is a problem in our industry. After all, Software Engineers are most definitely NOT known for their social skills. The emergent properties of human interactions over time is a very complicated problem.
If you dump some personal code of yours in a public place (which you would have written anyway) can it be really called a donation?
If you don't plan on even considering ongoing issues that are well documented, can you call oneself a "Maintainer"?
It would be very useful to a-priori distinguish the expectations for a given repo, is it "I dumped my personal code, don't bother me" or "this is a maintained project"?
It feels like the "Old World" of open source was mostly about passionate people developing (and open sourcing) software for other similarly passionate people (think of some of the great projects on Freshmeat 20 years ago). I am not saying it was perfect but there used to be some sort of etiquette.
Now the demographic has changed drastically. On the "maintainer" side you have a lot more people just dumping their stuff on Github (public repos were the only one free) and only want to collect the positive ("feel good", resume padding).
On the "Consumer" side you have way more people that completely abuse online helping channels such as StackOverflow, or Github issues (how many times have I seen someone say "hello it does not work can you help me").
It reminds me on how IT departments evolved in Corporations where years of abuse lead IT departments to develop a very conservative defense mechanism that basically leads to the function being solely self serving.
I am shocked reading this thread that it has become completely ok to flat out ignore legitimate and well researched/documented bug reports. Feels like we are throwing the baby with the water here.
The web framework situation has also been a problem for quite some time. No clear stable equivalent to jetty, flask, go's net/http. Great that Diesel (which looks great) is making it to stable. I really wished it was stable 3 years ago.
On that note it would be great if crates.io would have stable/nightly compatibility as a primary concept/badge/filter. I can't think of any other mechanism to nudge library developers into supporting stable as a first class citizen.
Rust in prod has been bittersweet for us. Our main goal was to 1) do our job and 2) leverage some of the great promises of Rust.
Deterministic memory management and bare metal performance are great and have been realized benefits. The great promises were realized.
On the “do your job” front though, the lack of a good STABLE library ecosystem has been a real issue and big source of frustration. It seems that most library developers in the Rust community are hackers writing Rust for fun, and I do not say that in a negative way. But the consequence is that things are usually not super well maintained, but more critically are targeting Rust Nightly (which makes sense as Nightly has all the new cool compiler stuff).
Add the scarce professional talent pool, the unavoidable steep learning curve, low bus factor risk... It’s just hard to justify pushing (professionally) more Rust beyond its niche.
With Mozilla pulling out (to some extent), the big focus on Web-assembly... it just feels off if all you want to do is build boring backends.
The contrast with Golang’s “boring as a feature” is quite interesting in that regard.
Time will tell if Rust will make it to the major leagues, or will be another Haskell.
They're also better at detecting bullshitting from engineers.