jsherwani

Since leaving Slack, I've been building Pop with a new team. The first product we launched in 2020 is essentially Screenhero 2.0 (pop.com). Since then, we've been building an expanded product: a virtual office for remote teams, which is now almost ready for launch (there's a waitlist at https://new.pop.com). We've even got Wayland support in! We have plans to open source a part of the Wayland piece, which Petal could potentially use too.

I do love this space, and wish more tools were about live collaboration — it feels so much more human and fun than single-player mode. I hope Petal becomes a growing community that thrives for the long haul!

He is getting a refund along with an additional $200 credit from what I can see.

In my example, the tax rate isn't the point though, it was used just to illustrate the math.

The main point is that it makes no sense to require amortization of software development expenses. The idea that this letter is an attempt to restore rationality in the tax code.

- A business is usually taxed on its profits: you deduct your revenue from the cost of producing that revenue, and the delta is what you are taxed on.

- In software businesses, this usually means if you spend $1M in software development to develop a web app, and it makes $1.1M in that year, you'd get taxed on the $100K profits.

- However, a few years ago, the IRS stopped allowing the $1M to be deducted in the year it was incurred. Instead, the $1M was to be amortized over 5 years, so now the business can only count $200K as the deductible expense for that year. So now it's going to be taxed on "profits" of $900K. Assuming the tax rate is 20%, that means the business owes $180K in taxes, even though it has a total of $100K in the bank after the actual expenses were paid. So it would have to either borrow to pay taxes or raise venture capital, meaning that VC-funded companies would be advantaged over bootstrapped ones!

- The letter's goal is to bring things back to how they were (and how they are for all other businesses): let businesses deduct their actual expenses from their actual revenue, and tax that actual profit.

I am neither a lawyer nor an accountant, this is just my understanding of this issue.

Edit: Switched the tax rate to 20%. The logic is still the same.

And, zooming out a little more, free market healthcare is just part of the problem.

We have a system where we’re only treating people once they have a disease, and not working to prevent the disease, so it would be helpful to look at the effects of for-profit companies on making healthy people sicker. Fast food, snacks, alcohol, there are so many industries that are incentivized to succeed by making people sick.

This is the system “working” according to the current rule set.

It’s time to look for a better algorithm than a purely profit maximizing one.

What’s far more “normal” is storytelling (with heroes and villains), rhythm & rhyme, and lots of repetition. But even simple conversational interfaces are way more normal (and fit our mental hardware well) than terminal-y interactions.

http://www.cs.cmu.edu/~jsherwan/pubs/orality-hcid-itid09.pdf

Based on the discussion, we're going to look a lot deeper into finding ways to reduce Electron's memory bloat especially when idle, and reduce CPU usage when screen sharing by attempting to offload the most computationally intensive parts to purely native code, while still leveraging Electron as a unified, cross-platform presentation layer. We'll report on our progress on this front, and our goal will be to get the best of both worlds: one cross-platform code-base, coupled with native levels of performance.

[1] https://news.ycombinator.com/item?id=28230542

Based on the feedback today, we're going to look into how we can reduce memory usage overall (especially when idle), and CPU usage especially when screen sharing. We already modify Electron, so we may be able to work out a good middle ground that reduces the footprint significantly, while still giving us the advantages of a shared codebase across our 4 platforms (Mac, Windows, Linux, web).

In short: when you need to see anything outside the IDE (e.g. a debugger, or even just seeing the running app alongside the IDE), a tool like Pop is very helpful. But you can also use it in conjunction with those IDE features, as Elijah in the above thread said he does.

With Pop, you can minimize the control panel with 1 click. We'll soon also be adding the ability to remove the border around your shared screen entirely (some users have told us it gives them anxiety to not see something that clearly shows them that they're sharing their screen, but we've now heard the opposite perspective from enough people to realize we need to support both preferences).

And honestly, the feedback on Pop as a name has been overwhelmingly positive :)

I think one key piece worth emphasizing was: Screenhero's core strength was in its interactive screen sharing. Slack's main desire was in voice, then video, then screen sharing, then interactive screen sharing — and this "impedance mismatch" is somewhat responsible for where things ended up. By the time we got to the end of that roadmap, the appetite for the final feature was low, while the cost was very high.