You can easily do this today, just start a mastodon instance and restrict the signups. I run a > 100 user instance on just a $10 digital ocean VPS. I'm seeing small tight-knit community instances popping up all over the place. You can tweak the settings or or even add customizations from forks that cater more to a siloed instance.
I'm shocked by the comments of those here that don't see why something like this must exist and don't see that there is tremendous financial upside for whoever cracks this. Employee equity can generate unbelievable amounts of wealth as well as unbelievable tax consequences/missed opportunities. The deck is mostly stacked against employees, and you're on your own navigating treacherous waters with little information. A strong company in this space can protect employees and ultimately advocate for them and improve the landscape. Or it can augment the deck being stacked in favor of the investors etc. depending on how things shake out for the winners in this space.
>I'm shocked by the comments of those here that don't see why something like this must exist and don't see that there is tremendous financial upside for whoever cracks this.
Some of us don't live inside the Bay Area startup bubble. I've never worked for a place that has offered equity, I've worked for publicly traded companies and the government. For the vast majority of Americans (and the world) this is a situation where we will never see ourselves in, so some of us see this as a weird business idea given the incredibly limited market that relies on a booming economy resulting in VC money funding startups to survive.
As someone else in this thread said, this is a startup for startups.
I can see why YC funded it "we exist to fund startups, startups offer equity when they can't afford to pay employees fairly, of course we'll fund a startup that helps employees of startups!".
However the problem here is, YC has never existed with their current model during a recession. Y Combinator was founded in March of 2005 with what like 8 companies and a much smaller contribution, the recession started a few years later.
Fast forward to last year and they had 273 companies present at demo days between winter and summer batch, at what 150k a pop? What happens when we enter the next inevitable recession? Will accelerators like YC have 50 million dollars (given the events they put on, I imagine you can at least round up to 50 million) to fund startups at these levels? Or will they have to drastically dial back and fund considerably less companies and focus more on the continuity fund and additionally funding companies that are seeing growth?
Then enter Compound, relying entirely on startups popping up offering equity. Enter a recession and a lot of startups are likely to fail during tha tperiod because VCs will be less inclined to take on risky investments, companies and consumers will be less likely to take on buy new goods or pay for new services, and then Compound is suddenly like "whoa, if there's no startups offering equity we have no customers, we don't have any other product ideas!!!" Press Release: Company Compound has shuttered, in a noble gesture Compound posted all employee resumes on the website and urge companies to consider interviewing these now unemployed persons.
This is a problem I consistently see with YC companies and VC in general the Bay Area exists in a alternate reality, or fantasy, bubble that does not resemble the rest of the country or how most Americans lives are. That isn't sustainable. I mean you have all these SaaS companies -most Americans have no idea what software as a service is and doesn't need to have their toaster tweet that it is toasting the 17th piece of toast this week so that D0ughb0x can ship more artisanal gluten free free trade gmo free bread and notify the Ca$#p@y app that the subscriber's digital life companion Phriendly should request authorization for payment-.
Ok, maybe that example is a bit ridiculous but seriously, look at a list of the companies for the past few YC batches... there are some absolutely ridiculous ideas, most of these companies will fail miserably and would NEVER have been seeded during a recession, what happens to Compound when startup numbers plummet and they can't find customers to educate about equity?
Great to see such candid comments and this clearly shows you actually really care about this startup's mission "Compound is entirely focused on helping you—the employee—understand and manage your equity."
(Full disclosure: I've been following this founder for a while to see him do great things)
"there are some absolutely ridiculous ideas, most of these companies will fail miserably and would NEVER have been seeded during a recession"
So, to state the obvious here, recession is actually one of the best times to start companies or join solid startups to earn early-employee equity: fortune rewards the bold. And to some extent, that's the best concentrated personal wealth investment if you choose wisely which early-stage startup to join, especially when you don't have lots of cash sitting around to "buy the dip" from public market. So why not "join the dip" to take advantage of the recession years (golden era, blessing in disguise) to become equity rich coming out of the other side?
I believe it's true that many/most non-VC-funded startups don't give employee equity, but don't you think this situation actually also needs to change? Just like now remote/distributed work is all the rage, in 5-10-20-25yrs when most/many other companies also give employee equity for them to have the opportunity to "earn concentrated wealth" from 'investing in" what they work on at the company?
I see Compound's mission very aligned with employees at all kinds of companies of different time, start from a smaller focus market (VC-funded startups), to serving majority of the planet in the future :)
> look at a list of the companies for the past few YC batches... there are some absolutely ridiculous ideas, most of these companies will fail miserably and would NEVER have been seeded during a recession
Out of curiosity, what is the problem with people trying "ridiculous' ideas? Airbnb and Uber were considered ridiculous at the time and look how that turned out. Sometimes ridiculous ideas can turn to fantastic companies that add economic value to the world. The opportunity cost of not chasing these ridiculous ideas is worse than otherwise if you ask me.
Over the years I've tried a leap, gesture, HON exposure, aeron, and embody... and after all of it still find I vastly prefer a $70 Ikea Millberget to all of them https://www.ikea.com/us/en/catalog/products/00331707/ - the cheap material starts to flake after about 2 yrs of use so I'll just buy one every two years I guess.
I guess the lesson is that every body is different and you gotta find what works for you
The hon is pretty good, but the way the back tilts isn't super comfortable to me, and also the arm rests are a very hard plastic. I put padding on the top of the arms, but then the height of the padding combined with the fact that you can't lower the arm rests quite enough means that they sit a bit too high for me.
I 100% agree with the author on this. VR in its current iteration is clearly not suitable for this in any way, but down the line the fundamentals of VR align perfectly with some of the pain points of remote collaboration. With all current collaboration tools the parties are still bridging the gap of working in different places. In VR, everyone is inhabiting the same virtual space. It's just completely different. Practically, all things switch from n representations to 1 representation. Psychologically we register the interactions completely differently because the parties are saying things not in their room with a video displaying them in your room. They're saying things next to you, to the person sitting across from you, while turning and walking away. The fidelity of interactions (and in turn the interpersonal bonds and memories you form) is just an order of magnitude higher.
If hardware is good enough for this to be a practicality, we may be working in AR 100% of the time anyways, and depending on if you want to be remotely present with others, you just swap out your real environment for a shared virtual one. In that dream scenario, the glasses or whatever are high enough res anyways you'd rather use them to make virtual dynamic user interfaces than stare at a static 2d monitor.
It's going to be a long, long, long time before any of this happens but I'm guessing these are the kind of far-off things the author was implying.
Maybe. But once you posit "long, long, long time" and the current iteration clearly not being suitable... Sure, some far future xR technology will almost certainly improve remote interactions and collaboration. But it almost certainly doesn't look like what we call VR today.
Facebook deemphasizing clickbait content reliably hurts their metrics. YouTube deemphasizing extremist videos reliably hurts their metrics. This metrics-driven product development was totally understandable (and I even tried to do it) up until a few years ago when we simply got too good at it and it ripped the world apart precisely along the seams where the human brain has bugs that cause these things to increase metrics.
Email prefill replies are a silly and relatively harmless example to make this case, but the point is every last button on every product we use is caked in this and we're realizing too late that metrics identifying what humans want often does not coincide with what humans want being good.
People may not say no as often, but one no can be very powerful. It's harder to say no. Billions of people nudged towards saying yes is not nothing.
I was just as entrenched but am about a year into a gradual transition. Signed up with another email provider with an address @ a domain I own, transferred my entire mail history, forwarded all incoming gmail emails to new provider, updated all public facing contact @s to new address, switched mostly to open source email clients, all new accounts are made @ the new address, old ones stay @ the old one. It's not perfect and it's not trivial but it's 100% worth it.
I'm a layman, but to my knowledge navigating a digital environment and a real one are the same minus some steps of the process. A self-driving car recreates a digital reality via sensors with as little delay and fidelity loss as possible, then navigates a digital car within that rapidly constructed virtual reality. It then signals back to the real car to navigate the real car exactly how it would navigate the digital one given its immediate digital environment. Since many of the hard problems lie with the navigation in the digital space, removing the sensors-to-digital part of it by training with video games still nets a lot of valuable learnings that can be brought right back into real-world applications. Also, learning in a fully digital environment allows this part of the learning to be done without the spatial/time constraints of reality.
games are simulations of idealized processes using generally a small number of equations. a sufficient neural network should be able to learn them but the real world has orders of magnitude higher complexity. Something similar happens with robots trained with physics engines.
This (or something like it) is always the top thread. I wish this was something the frontend community cheered about, not lamented. Those 200MB of node modules are developers ad-hoc cobbling together an alternative to xcode and android studio, except entirely modular and where we have complete control. Serious application development for the open web is hamstrung by limitations and definitely in an awkward growth phase, but it's marching towards a possible future of competing with native mobile apps and the two companies to which they're entirely beholden. To me, 200MB of tooling is not a sign of cruft, but of steady and imperfect progress.
Edit: and for the record, xcode is a 13.8GB install
> The set of dependencies that Create-React-App uses includes:
> A compiler. a bundler/linker, an optimizing minifier, a linter, a development server with live reloading, and a test runner
All of those are isolated and scoped to that one project, and they are all build-time dependencies only. It's also important to understand that Javascript packages are effectively distributed as source, which affects the number of files on disk. (Granted, many NPM packages do include unnecessary files in the published artifacts, but Javascript itself is a major factor there.)
As you said, a full-blown IDE like XCode or Visual Studio is easily multiple gigs, and if you were to look at the actual file size on disk of any C++ compiler toolchain, that would be a minimum of dozens of MB - those are just usually preinstalled on Linux or Mac systems.
So, context is pretty important here. A couple hundred MB for a complete JS build toolchain is understandable. I don't think it's necessarily _good_, and I think it can be improved a lot (especially with upcoming tooling like NPM Tink and Yarn PnP), but it's not the catastrophe many make it out to be.
Here's an interesting observation from recent HN reactions to JS:
+ The hardcore server folks are hating JS these days, because it requires more than dropping a single script tag.
+ The full-stack people / JS beginners are hating JS with a passion, because they think it's unneeded complexity for
their deadline.
+ Advanced JS veterans totally like how the JS ecosystem is rapidly maturing & solving its problems in interesting ways.
And there's people like you (the latter), constantly explaining the former groups that JS isn't so bad.
I'll see if I can write a blog (or a book if it has to be) on each part of JS ecosystem that has changed with detailed explanations on why it is better.
I think this is all true, but one important factor is that there's currently an assumption that any serious project must necessarily use all this complexity, which makes your second point true - but not in a way that's the fault of javascript, but more the community around it.
If you're making a simple site, or even a fairly simple application, the typical modern Javascript toolchain is absolutely unneeded complexity. It's not even React - many developers will turn their nose up on anything that isn't using Redux / Typescript / GraphQL / whatever flavour of the week is popular, even on sites where Javascript itself is probably not that big a requirement. As an example, we're all talking on a site that has almost no Javascript and works perfectly well - but I have no doubt that if you hired a developer to build a site like this in 2018 it would absolutely use a typical complex setup.
That isn't Javascript's fault, really - no library demands that you use it for everything, and many like Redux make it a point to push users away from using them inappropriately. But the Javascript community is currently in a phase that's probably unhealthily pushed towards the new, shiny, more complex library, regardless of how well it suits the problem.
I have to agree with you. The shiny stuff syndrome is spreading like cancer in the front-end world.
The only way to set this right is: when you create something, don’t sell it as a one size fit for all solution. State the tradeoffs as loud and clear as possible. Guide the users on what point you necessarily need the library and point them to simpler alternatives when needed.
This is something I deeply respect about Dan Abramov. He did this with Redux. Now that he’s in React, I see a lot of this culture in React docs as well these days.
Bottomline: The responsibility is on the creators to stop spreading this shiny stuff syndrome.
I will say that as a current Redux maintainer, I _hate_ that I seem to have to spend more time cautioning people about when it's appropriate to use Redux, than I do actually promoting its use. :( I can't think of any other lib off the top of my head where the maintainers have had to do that.
That said, yeah, we've got a Redux FAQ entry that discusses when you should use Redux [0], and some other "caveat"-type sections scattered throughout the docs.
We're currently planning a revamp of the Redux docs structure and content [1], and we'll see if we can improve some of the messaging as part of that. Would appreciate any suggestions you can offer.
> many NPM packages do include unnecessary files in the published artifacts
This is the main reason node_modules grow so quickly. Many authors are careless on what files they include in their published packages.
The npm cli now makes the package files and size visible during publishing, but I guess we need some way to shame authors publishing big packages, maybe by including size info on the npm website and downranking them in searches.
In June of last year, I had to prepare an offline Visual Studio installer for an isolated environment - the install package (with all available options) weighed in at over 50gb...
Right, exactly. Now, that can be broken down into smaller chunks based on what toolset you're intending to work with (C#, C++, web, SQL, etc), and the sizes for each toolset vary, but clearly these toolsets take up a lot of space.
visual studio code and browser are about 50 mb each. That brings a complete web dev setup to maybe 300-400 mb. Oh and I can build desktop apps and mobile apps too with web tools, still never coming close to 10+gb.
Yeah, it is completely missing me how web application dependency libraries relate in any way to an IDE for building applications. I don't get this argument and it doesn't seem to me like it makes sense. Perhaps I'm wrong and there's a connection I'm not seeing. Can anyone clarify this?
The point is that build tools take up disk space, and need to be installed. IDEs like XCode and Visual Studio bring along large quantities of libraries, headers, and other aspects of a C++ / C# / Swift / $LANG build toolchain.
Front-end web dev now consists in large part of building highly interactive applications, not just static sites. That requires tooling. Therefore, it's not unreasonable to expect that the necessary tools will take up space, and there's plenty of prior precedent from other languages.
The lion's share of my node_modules are related to my development environment -- Webpack, Typescript, Babel, SASS, Jest, etc. A very small portion actually gets bundled into the dist.
Those 200MB of node modules are developers ad-hoc cobbling together an alternative to xcode and android studio, except entirely modular and where we have complete control.
You just made up a fictional scenario and used it as the evidence for your case.
I tried to do the same during a bout of extended international travel. I popped out the fi sim once to try a super cheap local unlimited data sim (some countries are great for this), only to find out afterwards that it killed the fi pairing, and that re-pairing is not possible while abroad (tried VPNs etc., no dice). Your only method to get paired again is to either fly to the states (Hawaii), or to ship the phone to someone in the states and have them ship it back. Ended up having to go months without my main cell service, although months later it did somehow pair again while I was in Japan.
Keep in mind that you'd be just as out of luck if you wanted to switch phones while traveling, like if your primary was lost or stolen. For that reason, I canceled fi immediately upon returning to the states and strongly caution anyone I know against fi for extended travel.
Weird, I haven't had that experience -- I've switched between Fi and my work SIM several times while abroad using the chooser in my Pixel 3's settings… Did you perhaps somehow reset your eSIM?
Edit: ah, you were using a physical SIM. Mildly ironic that you'd have a worse experience "re-pairing" than with an eSIM.
Related anecdote: at 34c3 last year, I was able to activate Fi while in Germany, but 6 months later, no matter how many agents I talked to (none of whom identified being in Europe as the problem), I wasn't able to reactivate it in Europe. This was because I had paused my service and switched phones, and they apparently implemented checks to prevent activation outside the USA.
Or, I was the accidental beneficiary of the various GSM hacking going on at Congress, and it never was supposed to work in the first place.
Curious if it'd be effectual (although impractical) to use an AT&T femtocel to activate while abroad…
