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.
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.
> Now... if you exercise the option, that is a different story.
You exercise if you leave, and startup IPOs can take many years, and most startups don't have a compelling options package for you after the first 4 years anyway.
So a senior engineer who got their full 4 year equity and wants to leave, which is the most typical scenario, will indeed have to exercise and get hit by the tax bill.
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.
Startup engineers are often young and do not have much savings.
Options are a cost, often in the 5 to 6 figures range to exercise. If you exercise at time of hire, your cost can be significant for something that will probably perform less than putting it into bitcoin as far as expected value goes. If you count exercise cost as part of the 'salary', then startup salary is even worse than it usually is.
When you leave, the options expire away typically after 90 days. If you exercise, even if they are ISOs, AMT tax can easily make the exercise cost 6 figures anyway. Most engineers in their mid 20s do not have 6 figures in savings unless they already worked at FANG for the first 4 or 5 years of their career. You have to choose, do i put most of my savings into something that will probably go nowhere? Most do not and lose out on the significant compensation they would of at FANG. It's a system that favors the already wealthy and young adults with wealthy parents.
Companies actively try to prevent giving liquidity to employees through restrictive clauses. The best case scenario is an employee that works hard and then forfeits their equity due to the above math. The company has a financial incentive to screw employees over and seduce them with unlikely projections of life changing wealth.
-----
On the other hand, founders have stock at the start, valued at $0. Even if they have a vesting schedule, they can pre-exercise for no cost. Since it's extremely unlikely that they will sell in the first year, all of their income from that stock in the future will be taxed at LTCG rates. Since the average employee can't afford to pre-exercise (or they get RSUs), they pay at income tax rates, so if they do get lucky, they've compressed 4-8 years of equity compensation in one year, which means they pay %25-%35 more in income tax alone. Employees are often subject to 6 month lockups after IPO, which means if it drops, they have to pay tax on a value that is much higher than they can liquidate with the stock they actually have.
Founders often get special liquidity access that employees don't, in secret, during funding rounds. VCs do this to align the founder's interests with theirs, which is going for an outlier $10B IPO vs. liquidate at $300 million at series B, because if the founder has %20, that is a life changing $60 million, taxed at LTCG rates, that makes you an ultra high net worth individual, but is basically a failure from the VCs perspective.
> 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.
Right, so the bottom line is this:
After 4 years working at the startup, unless it already went bust, you will typically want to exercise, and then you'll get hit by a big tax bill for purchasing a security which is still very likely to end up at zero.
It's a risk no matter how you look at it. Unless you happen to work at a startup that became a unicorn, which is very rare, you will end up paying good money for something that may be entirely worthless.
So in the best case scenario, you take a risk for an upside that may put your comp around the same level as what you'd get for simply working for FAANG. Worst case, you pay a big tax bill that drops your comp even farther below what your friends at FAANG are making, which is already going to be twice or more to begin with.
Surely you see the problem here, especially for risk-averse engineers.
You don't _have_ to exercise if you leave. That part is totally optional - in fact, the company will probably be quite happy for you to leave without exercising.
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.
> which makes the grant neutral from a tax standpoint.
Technically, it also makes the grant neutral from the value perspective. They’re giving you something worth $X, and asking you to pay $X for it. Why exactly should you value it more than $0 then? Maybe for the optionality, but ATM option just isn’t worth that much...
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.
> It turns out Kubernetes is actually perfect for small teams
As long as at least one of them is an expert on kubernetes. In this case, the one person in the team is that person, and as he points out in the article, he's using it because it's what he knows.
That should be the takeaway, I think. The "trope" remains pretty sensible IMO; I've seen it first-hand, jumping on kubernetes without the know-how is a foot-gun factory, and that team ultimately gave up on trying to implement it.
I use DigitalOcean's managed kubernetes for one of my side projects that I did with a friend. Really happy with it. And it's actually cost-neutral: all you do is pay for the $10 droplet it runs on and you get the managed k8s at no additional cost.
I've done a complete 180 on this too, I realised I was reacting from my default position of hostility to new concepts rather than an honest appraisal. I am writing it up at the moment but I've been working on a 1 person SAAS MVP tutorial [0] and though I've definitely misconfigured something having the ability to go from git push to deployed to production with 0 downtime inside of 5 minutes with no manual steps is such a nice flow, versus my previous attempts of SCP and faffing around with services.
> Kubernetes aims to provide all the features needed to run Docker-based applications including cluster management, scheduling, service discovery, monitoring, secrets management and more. Nomad only aims to focus on cluster management and scheduling and is designed with the Unix philosophy of having a small scope while composing with tools like [Hashicorp] Consul for service discovery/service mesh and [Hashicorp] Vault for secret management.
> Nomad is architecturally much simpler. Nomad is a single binary, both for clients and servers, and requires no external services for coordination or storage. Nomad combines a lightweight resource manager and a sophisticated scheduler into a single system. By default, Nomad is distributed, highly available, and operationally simple.
Like all of Hashicorp's tools, they are more complicated and error-prone than they first appear, because they stuff too much functionality in one binary. But it does let you implement one piece at a time, so you can make incremental improvements as you need them.
What do you think is "too much functionality in one binary"? With Nomad I feel like the opposite is true: Nomad is just a workload scheduler. If I need service discovery I can add Consul, if I need secrets management I can add vault. Honestly curious by what you meant exactly and how Kubernetes does it better / easier.
Kelsey Hightower's 'Kubernetes The Hard Way' [0] "is optimized for learning, which means taking the long route to ensure you understand each task required to bootstrap a Kubernetes cluster."
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.
Yeah the key to having the penny pinching DIY approach pay off is to have your time already close to zero. Then you can take as long as you want to perfect your CI/CD pipeline and loading screens, they will all pay for themselves in the end.
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"?
Simply allowing people to see your code doesn’t give them any rights to use it. OSS provides a license that allows you to use software without paying the creator, that’s the donation.
As to being a maintainer, if you’re using that code for something and updating it whenever you personally have a problem that’s still a maintainer. Consider a geologist who created an absurdly accurate GPS for exactly the hardware they have. If’s it’s working for them they might go years without making an update, and that’s fine. Someone saying there is a bug when used on farm equipment simply is’t their problem. Even a different geologist seeing issues south of the equator isn’t their problem. The software is free and almost sufficient, feel free to pay someone if it’s not doing what you want.
The core issue is OSS is free to use and modify, but that also means the maintainer is free of all obligations.
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.
I think you’re confusion is around the most well known OSS projects which try and increase adoption and generally request donations. That’s a relatively small chunk of the overall OSS community which is well known specially because maintainers have a personal desire or financial incentive to increase adoption.
Far more often projects are released as OSS because sharing a project is a net benefit to the world and costs the donator nothing. That’s really the central idea of the OSS movement, when copying is free it’s easy to be generous. Forcing a social obligation is therefore toxic to the OSS community as releasing software becomes expensive.
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.
I'm seeing "x accepted pull requests" on resumes frequently now. Not every PR is made in good faith nor made with the same motivation as the maintainer. Someone making dozens of individual PRs for things like adding CONST to variables whose future use they do not understand is a drain on the maintainer's time. For the person making the pull requests, they get a low effort way to pad their number of accepted pull requests, many of which are not in alignment with the goals of the maintainer or the project.
Totally agree. I by no means think all PRs or issues are equal. That's basically what I'm irritated about with this post! The new attitude that I hate is treating everything as crap, spam, or entitlement. Politely refuse low effort and unuseful PRs. Don't throw the baby out with the bath water.
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.
Most libraries don’t target nightly anymore. It certainly used to be the case that nightly had all the cool features everyone wanted, but almost all features that popular crates depended on have now been stabilized. Even Rocket (the most high-profile holdout I know of) now works on stable as of earlier this year.
As for maintenance, as with all library ecosystems it’s a mix. The most popular crates tend to be the most well-maintained in my experience. This is definitely something to consider when taking on new dependencies.
Many things that used to nightly don't anymore. I think the only thing I'm using on nightly is Rocket, and that's set to change soon. May I ask what it was?
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.
I would love the stable/nightly badge on crates.io, that's a great idea. OTOH, it is nice that some libraries use nightly though because that provides some nice feedback. That said, some crates hide nightly only functionality behind a feature flag, and that'd be great to expose too.
The web frameworks seem to be coming along nicely. I think the main reason for stagnation was the unstability and flux around async. Actix (stable), Warp (stable) and Rocket (stable in the next major release as all nightly features have stabilized) seem to be the strongest contenders at this point.
> (stable in the next major release as all nightly features have stabilized)
I initially misread this comment; what you are saying (and what is true) is that all the features it was using are now stable, but the version that uses them hasn't been released yet. I initially thought you were saying "once all its features are stable."
They're also better at detecting bullshitting from engineers.