Also, this is the most compelling reason I've seen so far to pay a subscription. For any business that merely relies upon software as an operations tool, it's far more valuable business-wise to have stuff that works adequately and is secure, than stuff that is new and fancy.

Getting security patches without having feature creep trojan-horsed into releases is exactly what I need!

My theory is just that the cables came in the box and are screw-on when more modern connectors are friction fit, and the IT departments don't want the hassle of "they just got pulled out." Which should have been predictable - but I can literally see 12th gen Intel, paired with 1080p display, over VGA fairly regularly.

Source: Too many years experience in the desktop support trenches.

Correct me if I'm wrong, but if a company hires someone to say, mine coal or brew beer, the expense of those employees is an expense any company can claim a full tax deduction on. If you're a line chef or wait tables, your salary is tax deductible to the restaurant.

So it's not that we are asking for R&D to be treated "specially" and get a deduction that other companies don't have. The problem is that R&D salary expense is being singled out as producing an asset (e.g. IP), and thus being classified in the same category as other assets, like, brewing equipment, a mining excavator, or a pizza oven. Simply put, Section 174 argues to classify people in the same category as things because ... 'these people's work outputs may have long-term value, kind of like things'(?).

Allowing Sec 174 to stand is a slippery slope to classifying more and more everyday Americans' salaries into this category. One could argue in the future, for example, that those who design cars or operate machines to produce tooling dies, should not have their labor treated as regular expenses, but instead as capital assets because their labor output is captured in assets, just as Sec 174 treats the labor of software developers as assets. Everyday people should be concerned by this because if the rule stands, it could be extended to you, too.

For those objecting to the equal treatment of R&D employees as all other employees in America of all stripes and vocations, keep in mind that software people have to pay personal taxes on the income, just like everyone else. Section 174 doesn't have anything to do with personal income taxes: we all pay income taxes fair and square. The question is whether there is a double-tax on software labor, paid at the corporate level (and in all likelihood, your salary is currently a tax deduction for your company, unless you write software or do R&D).

I think the assumption that we are asking for "special treatment" is driving some confusion and grass-roots objection to the movement here, so I wanted to highlight that we are just asking for everyday people who work software and other R&D jobs to be treated just like every other American who works a day job.

[edits for clarity]

The question is: are you getting the value of that work in the same tax year, or is it creating an asset that creates value over time? If you hire a guy to brew a batch of beer, you’re getting the value with that batch of beer. Once you sell that beer, the value is gone.

But if a brewery hires someone to build a fermentation system, then that person’s salary cost must be allocated to capital expenses that must be depreciated over time.

There’s a good argument that most software development is creating an asset that pays off over time. If you hire someone to upgrade the payroll software, you’ll get the value of that in future tax years.

A better analogy is a brewery hires someone who builds a fermentation system, then continues to operate, maintain, repair, and improve the system over time. Some of the employee's time is spent on work that could probably considered R&D, some of it is on work that is clearly operation, and some isn't clearly one or the other. So how do you determine how much of the worker's salary is R&D vs operational expense? You can try and estimate some percentage, but that breakdown is at best an educated guess, and having to try and figure that out just adds pointless friction.

But that still isn't a great analogy, because in that case the fermentation system isn't the product, the beer is. So for a company that sells software, it would be more like if it wasn't a company that sold brew, but a company that rented out or sold its brewing equipment to other companies that made beer.

Also, the same argument about creating value that pays off over time could be said about most employees. An accountant could find a more efficient way to keep the books that pays off over years; the CEO could create a strategy that pays off over years; customer service staff could create a reputation for high quality customer service that pays off over years; etc.

And then, even if you assume that an engineer's salary is entirely R&D, then the only reason I can see to want that salary taxed at a higher rate is if you want to disincentivize R&D. R&D is already a large expense now in the hopes of a payoff later, and by increasing the tax burden now, you are making that upfront cost even higher.

How would Disney feel if the salary paid to the cast of the Avengers was no longer an expense in that year, but amortized over the entire copyright period of the film.

Doesn’t change much for the Avengers films which have production costs around $500m. Disney still has to capitalize 97% of the cost. $15m doesn’t cover a single star’s salary.

I think the issue is this fantasy that a software develop only produces long term IP. Or how is it different from an executive who is developing strategy and market positions that have future value?

Maybe it would make sense if we could distinguish such work products as a fraction of their total output, tracked as actual inventory that accountants have to assign value and track capital gains on?

For example, if you pay for someone to maintain the brewery plant to keep it working in its current condition, that’s an operational expense that could immediately be deducted. But if the work is on upgrades and improvements, that’s ordinarily would be a capital expense that must be capitalized and depreciated. A bookkeeping strategy isn’t.

Your other examples are off the mark, because the question is whether the investment produces an income-producing asset. Software generally is such an asset. The question of what’s an operational expense versus what’s a capital expense isn’t always clear cut, and is the kind of thing where accountants and tax lawyers have to make judgment calls.

The tax code has been optimized by the rich over the past century to extract profits out of industrial firms and that's where the difference comes from. $100 used to, say, produce a car or a cake that you then sell is immediately and fully deductible from tax because otherwise industrial companies just outright can't survive. Hell, you get to claim back/not pay any VAT and/or sales tax you paid for anything related to them. One way to see it is that these rules are designed to get money to the (existing, "old-money") rich, so when investors don't get money, the government doesn't get money.

If it's equipment for the company to use itself, then it has to be amortized, or more to the point, it means industrial companies can't do what Amazon did: use 100% of their free tax flow to grow "tax-free*" instead having to give that money to the government and investors (15-35% to government 65-85% to the rich, sorry, investors), so they can use it for their own ends.

I'm not judging one to be good or bad, just attempting to frame this correctly. I should perhaps point out, as a last point, that this is a massive difference between the US and European countries. In Europe, investors and governments try to have their cake and eat it too: there's tax due (amortization rules, or worse) on new company creation, on company growth, except of course, for the companies of the rich: you can grow financial capital in companies without paying a cent, money, shares, obligations, ..., just nothing else. That's yet another connection to the rich, to investors. New employees, new buildings, ... are double taxed, only money isn't. In Europe, there have only ever been exceptional cases where it was otherwise. In the US "tax-free" new company creation has been the norm for all of history except since Trump changed this rule.

* between quotes because they still have to pay income tax on any wages, sales tax on any purchases, ... it is very far from tax-free, but such companies wouldn't pay a dime to investors. If they did that would make it very hard to create new companies (which is what this regulation does). Amazon's great accomplishment is not AWS or anything like that but 2 financial accomplishments: first, avoid sales tax, second, avoid paying anything to investors. Whatever business Amazon is in is nothing but a tool for that financial engineering.

While there are software that are still in use from five years ago, there are plenty of obsolete software no one is still using made five years ago.

If we are making say, a point-of-sale software rolled out in a fast food franchise (let’s take Chick-fil-A since they have edge Kubernetes deployments), is it reasonable that we won’t add features to that software in 3 years? Perhaps.

What about bug fixes? Is that expense or should we expect time spent on bug fixes to also be depreciated in 3 years?

What about configuration? Does configuring that POS for new menu items count as software development, and therefore needs to be depreciated over the next 3 years?

Chick-fil-A has edge Kubernetes. Does the install and implementation itself counts as “R&D”? If we argue that configuration can be expensed, then would writing manifests be depreciable or not? What if we use “infrastucture as code” tools such as Chef?

What about say, excel sheets and macros? Or forget macros — just basic use of a spreadsheet. Some manager add in a summation to a column to compute totals. Very basic stuff. Is that software development? If it is, would that be depreciated over 3-years?

If we argue that this is normal use of excel and should not be depreciated, then why wouldn’t my normal use of a compiler and editor also count as normal use and should not be depreciated?

Whether it is 5 years or 3 years, the point is that unlike physical capital goods, software changes very fast, even if the underlying hardware wasn’t changing that fast. It is not always that expert designers build them — software can also be written in a way where end users modify them. We also use software to make software, and can rapidly change our tooling in a way that we cannot with physical capital equipment.

I see the merit in categorizing software as capital, from an economic theory point of view, but software also has its own dynamic that is distinct from physical capital equipment. A tax code that does not acknowledge that can bring more overall harms to the society.

> most software development is creating an asset that pays off over time

This is a fantasy.

Software engineers being taxed similar to brewery design engineers seems reasonable, not the person literally brewing each batch of beer.

If you're 100% allocated to a greenfield project that's behind closed doors until 2027, sure. But it doesn't seem like most software engineers are in that bucket. If anything, the industry has been consistently moving further away from that, with more agile methods, tighter feedback loops, etc.

The problem is that R&D and software development behave more like recurring annual expenses, not upfront investments in something like a building or industrial equipment. Small VC-funded startups may not exist long enough to reap the long-term benefits of depreciation.

Assuming positive inflation, the IRS receives more total, because the taxes they get paid now are worth more than the same amount of dollars they give back in later years. And if the company goes out of business, the IRS never has to give those taxes back.

How so?

To minimize distortion, the income tax must accurately compute “income”—the actual increase in wealth. Depreciation is part of that. To compute income, the net increase in wealth, you need to subtract costs from revenue. When you buy an asset, your wealth doesn’t immediately increase or decrease—it simply changes form (from cash to an asset). The actual cost is the depreciation on the asset, which occurs over time.

Say you buy a delivery vehicle for $50,000. In the first year, you make $100,000 in revenue and have $20,000 in operating expenses. What’s your income after one year—the actual change in wealth? You have $80,000 in cash after operating expenses, plus a vehicle that you can sell for maybe $40,000. So you have $100,000+$40,000 in cash and assets in minus $20,000+$50,000 in cash and assets out, for a $70,000 increase in wealth.

Calculated another way, you have $100,000 in revenue-$20,000 in operating expenses-$10,000 in depreciation = $70,000 in income. Now, over say 5 years, you’ll depreciate the full $50,000 cost, and the total dollar amount the IRS gets will be the same. But it will get more taxes in the first year, which due to the time value of money is worth more than getting the money in subsequent years.

The problem is those of us who deal with code only rarely are actually just building a vehicle. It's an ongoing activity that more resembles maintenance than the outright purchase of an asset.

Look at how much software is going to a subscription model. That only makes sense if there is ongoing improvement to the software.

How is that any different from hiring a bunch of people to write some software, that I then get the value of over the following years?

That’s not how it works in general (there are exceptions though): https://www.law.cornell.edu/cfr/text/26/1.263A-1

My assumption is, if tax folks in the US were looking Jealously at US companies with large Multinational presence declaring a lot of their profits abroad. They might have noticed that some of them have large dev presence in US, but through complex accounting, IP transfers, licensing and other actions are able to claim that majority of the value is generated outside of the US.

If a company had, say, 100k software devs, 50k in the US, and 50k scattered across other countries, but claimed the value of it's software was primarily in Puerto Rico and Ireland... In that case, I'd expect questions around the 50k devs in the US.

Is software dev the only activity where this is possible - no, but is currently by the far the largest and the largest growth industry.

When are we going to break the majors up already? Google should be like seven different companies. YouTube is bigger than Netflix for Christ's sake.

Demand antitrust enforcement!

There's so much value pent up and wasted in Google today that it'll be worth more as divisible parts. They're practically giving half of the value away for free and wasting it on implementing the same thing four times before cancelling it.

And Apple and Amazon...

These giants are basically stifling the US startup ecosystem and putting a valuation cap on innovation. They're also ripping apart other industries by moving in and undercutting costs with subsidized offerings detached from the underlying economics. They're like invasive species destroying the ecosystem, eating up everything, completely immune to competition. And if that's not reason enough for you, they're putting massive wage pressure on our profession.

For a long while now, every small US-based company I look at hiring engineers have their teams in South America or Eastern Europe.

Since we tried to go to a pay-as-you-go model on bills the tax code has turned into an absolute shambles as the congresscritters look at how to tweak things to "produce" (look at the IRA withdrawals--it produced nothing, just moved some money forward one year while creating a trap that many have fallen into) the desired revenue to cover whatever the bill costs without "increasing taxes."

In the future? That's how it works!

> just as Sec 174 treats the labor of software developers as assets.

[I was wrong about the following. I misread the text - and the submission title.] That's not what 174 does.

But I'd also observe that since business owners have to capitalize the wages of the machine operators producing injection molds, then there is an advantage to outsource the whole operation.

Comparing a procurement manager and a CNC operator [the person running the milling machine making a mold] paid the same amount, the CNC operator has a bigger negative impact on the businesses' bottom line, because the business can't expense most of the CNC operator's wages in the current tax year, whereas the procurement manager is generally accepted as fully deductible expense.

Of course, the labor that went into making the mold is effectively built into the acquisition price of the mold, so you haven't gotten rid of it by outsourcing it.

But, by building it into the price of an outsourced mold, one can delay the purchase of the mold to next year to improve the P&L this year, but you can't similarly delay the wages of the tooling operator to a later date.

So, when a CFO is looking for a way to improve the P&L in a given calendar year, there's an incentive to cut operators who build factories, tools, and other assets that have to be amortized, and replace them with more flexible outsource options.

Of course, part of the reason mold making left the US is wages are lower outside the US. But I'd say the current situation with software engineers is a datapoint that demonstrates the impact of expensable versus amortizeable labor on employee retention. It could be that if the tax code is not fixed, the same "CFO logic" would lead to more and more software being outsourced over time, as management is an immediate expense, but software engineers are not.

I suppose one can then argue, why should software engineers get special treatment compared to tooling operators; but then I would counter-argue that perhaps tooling operators should have gotten better treatment so we could have retained more of them in the US.

is manager of AI agents (especially when they become more productive and capable than people) going to be a manager or software engineer?

...no, not a manager.

Aircraft are also more productive and capable than people in specific activities, and useless wastes of money in others.

Not really. For example for L1, a visa for managers and executives, managing people isn't a hard requirement, instead it may be "employee’s ability to manage an essential function of the organization at a high level, without direct supervision of others", and thus project managers and architects and even senior engineers make the cut.

Handling capable AI agents would seem to fit if those AI agents perform "an essential function of the organization" and you manage them "at a high level, without direct supervision of others".

Example 4. Acquisition or production cost. D purchases and produces jigs, dies, molds, and patterns for use in the manufacture of D's products. Assume that each of these items is a unit of property as determined under § 1.263(a)-3(e) and is not a material and supply under § 1.162-3(c)(1). D is required to capitalize under paragraph (d)(1) of this section the amounts paid to acquire and produce the jigs, dies, molds, and patterns.

I thought it was for the first paragraph.

But I was wrong about 174, maybe you meant that.

This is bad for the economy and ultimately reduce our tax base.

About the only thing that doesn't happen is for non-reproducible privileges such as land, intellectual properties, the electromagnetic spectrum, etc.

So are you saying that 0% rate taxes would capture the most tax?

Yes. It’s a second-order effect. Imagine if there were a 100% tax: the government would probably get no taxes, because there would be no economy.

> So are you saying that 0% rate taxes would capture the most tax?

No. There’s a sweet spot. Everyone argues about where it is, but obviously 0% and 100% tax rates would both be problems.

If you tax inputs but not outputs, then a 100% tax rate increases the cost of goods and services but does not necessarily kill the business.

If you tax income, then a 100% tax rate kills all income. However, income taxes are usually progressively, so a 100% marginal tax rate places a cap on income, but income below that can exist.

If you tax profit, a 100% tax rate leads to shifting profits to reinvestment and salaries and benefits.

There wouldn't be any money to reinvest into salaries and benefits, because capital would not be deployed on a risky, potentially money-losing venture without the possibility of profit.

However if the tax is too high then it would cause land abandonment.

If you tax the usage of the electranetic spectrum too much, you would get no usage but the electromagnetic spectrum would still be there.

Yes, there are people who think tax==bad. Most people (and for a century or so) have understood that taxes are ultimately spent, and normally with a "multiplier". That is, on something which actually stimulates further economic activity.

Corporate profit, OTOH, normally just satisfies the rent-seeking economy, which is not productive in any natural definition. For instance, dividends and stock buybacks. Yes, some corporate profit feeds entrepreneurship, but that's simply not a large fraction of the corporate economy.

The state can still tax in two ways, taxes on undesirable negative extremity such as products that give you long cancer, and unreproducible privileges. I listed those examples. There may be ground for taxing extreme wealth but I want to see extreme inequality fixed first.

I am not even disputing that the government spending encourages economic activity, but we should at least not shoot ourselves in the foot only to heal the foot with another hand.

I am advocating for the interest of the state.

It had a huge impact on my personally, I'm a small R&D shop and basically I have had to end all risky long-term research projects.

In addition to the research costs, I'd also have to pay taxes on the research costs mostly up-front. Significantly, if the project doesn't work out, I'm still out of pocket for the tax money. It's a penalty for taking a risk, and it kneecaps American innovators in a globally competitive technology race.

The rules are even worse than the article notes because it double-dings open source developers. See Section 6.4 of https://www.irs.gov/pub/irs-drop/n-23-63.pdf. The relevant bit is here:

> "However, even if the research provider does not bear financial risk under the terms of the contract with the research recipient, if the research provider has a right to use any resulting SRE product ... costs paid or incurred by the research provider that are incident to the SRE activities performed by the research provider under the contract are SRE expenditures of the research provider for which no deduction is allowed ..."

The rule as written means contractors who write Windows drivers could deduct their expenses (as they would have no residual rights to a closed-source work product), but contractors who write Linux drivers may not (as they would have some rights to open-source Linux drivers).

That’s how it works for every business! If Jim Bean builds a distillation facility it has to amortize the investment in that over time. If the distillation facility doesn’t pan out, then it doesn’t get a refund for the taxes paid.

In general, costs for running a business (buying inventory) are immediately deductible, while establishing new business (building factories) has to be amortized, since the factory can be used for several years.

In software, the line is a bit more blurry - coding creates new IP (research), but is also required to keep many software companies running (maintenance) by e.g. fixing bugs and updating infrastructure. Here, the IRS has decided that all software development counts as research.

This would kinda make sense if you could hire programmers for a single year to develop software, fire them and then sell the software for 5 years, but I think that's rarely the case.

The people this tax code change hurts are those doing basic research. In the context of semiconductors, that would be a company like ASML (except they are Dutch, so they can happily continue their research practices) who took a decades-long bet to build their EUV steppers.

In the case of basic research, one could be spending millions of dollars on hardware prototypes when you know it can't produce any salable product. There's no upside profit to amortize expenses against: it's like building a distillery that you know can't produce a single drop of salable bourbon because you're working out a radical new distillation technique.

In summary: in basic hardware research, one could be spending millions of dollars to put a whole system together just so you can learn how it fails. It's a true "expense", with no path to amortization.

Now, in addition to making the right technical decisions, the tax law changes force the R&D teams to also consider how to amortize their experiments over many years. You now have have pressure from management to do things like stage prototypes and expenses in the right tax year so the company can continue to show a profit for the shareholders. You could argue that the lessons learned are perhaps IP that have "goodwill" value, but now you're opening a can of worms trying to price a fair market value on a negative result, and you're now having senior research staff spend more time arguing with accountants than directing research. You also have to get to that negative result within a tax year - which effectively penalizes any research project that takes more than 12 months to complete.

Same-year 100% deduction of R&D expenses is simple and it reflects the actual nature of basic research risk. Yes, it allows companies to convert short-term windfalls into long-term research gains by converting taxable profits into research projects, but I'd argue that's not actually a bad social policy.

I think US is probably unique among developed nations in having a tax code that punishes basic research; other countries at least allow it to be deducted. Some even allow super-deductions (e.g. you can deduct $2 for every $1 of R&D expense) or the research is explicitly subsidized through grants.

The argument for special treatment of research is that pioneers put their careers on the line to discover new things, so the rest of us can live in risk-free comfort; so, as a collective we give them some reward for taking that risk.

I suppose the counter-argument is that research incentives and subsidies are socialist "market manipulation" and violate the "free market" principle, and thus America is justified in sanctioning and trade warring with the rest of the world that is socializing basic research costs. That's an opinion one is entitled to hold, but we'll have to agree to disagree on that opinion.

    > Both TSMC and Jim Beam already have to amortize their production equipment over several years. I'm not arguing that this should be changed. This is because the primary risk taken in a distillery build-out or a fab build-out is if there is market demand for a known product. It's primarily a *business* risk, not a *research* risk.

But if a company starts extracting oil from a field they have to pay heavy taxes on that oil.

[1]: https://www.offshorenorge.no/om-oss/nyheter/2019/01/leterefu...

Is it just me or are you conflating two orthogonal things?

An open-source Windows driver would have the same issue, no? And a closed-source proprietary Linux driver privately written for some company wouldn't have this issue either, right?

I think it's fair to use Windows and Linux as stand-ins for closed vs open source because it's a very accessible example. And knowing the technicalities clearly doesn't undermine the argument.

We're talking about businesses here that would struggle with these tax rules. Which I guess is, mainly, contractors or startups. How common is it for them to write open-source drivers vs. closed-source ones? I would've imagined the majority of drivers in such cases are closed-source, on every platform. But I would find it interesting to hear if things are somehow different on Linux.

The Grandparent's point about that "it double-dings open source developers" is still correct and poignant even with this clarification.

I feel like I'm missing what subset of people this is, exactly. We're talking about businesses here that would struggle with these tax rules. Which I guess is, mainly, contractors or startups. How common is it for such businesses to release their software as open-source, vs. as closed-source? I would've (naively) expected most paid OSS developers to be funded by large organizations/businesses that have plenty of money to fund them, not small businesses/contractors that would be severely impacted by this law. Is this actually a large set of people?

https://www.igalia.com/ https://github.com/fossjobs/fossjobs/wiki/resources

The problem goes with the license, not with the OS.

The problem is that the license assigned says that anyone is free to use the code. Anyone is a set of people that includes the contributor, which then triggers the interpretation that the research is incrementally in the contributor's benefit and thus disqualified from preferential tax treatment.

You'd need a custom license where everyone in the world could use the results except for the contributor, and then like, a source control system that hides the source files from the contributor's view of the repository.

Should every other member of that set, i.e. everyone minus contributor, also amortize their software development expenses because they have a hypothetical, non-exercised right to use some (i.e. all) open-source "R&D" software... somewhere? Or should the tax liability be invoked starting on the date of first use of any open-source code?

If some code is upstreamed to Linux kernel or userspace, should this obligate every Linux distro consumer to amortize their Linux software development expenses?

There must be _some_ legal boundary for dispersal of the tax obligation with respect to open-source code, since it self-evidently cannot be intended to apply to the entire universe of businesses and union of all OSS development. If necessary, a court case can establish this distinction.

How would that work?

> You'd need a custom license where everyone in the world could use the results except for the contributor

That one is incompatible with copyright laws in many countries outside USA.

How so? You can't sign away your interest in a copywrighted work?

For many open source projects, there is a CLA (contributor license agreement) that must be signed before contributions can be accepted. The Free Software Foundation (which holds the copyright for most/all? GNU tools) is pretty in/famous for requiring it. Their reasoning: If there are copyright violations, they have the time and financial resources to pursue the violators.

Are you saying that these CLAs and their intended purpose are invalid in some jurisdictions? If yes, please share some examples. To be clear: I'm only interested in "normal/regular" jurisdictions that have at least accepted the Berne Convention.

> You'd need a custom license where everyone in the world could use the results except for the contributor

> That one is incompatible with copyright laws in many countries outside USA.

Does authorship confer usage rights?

Have the shell company write code. (Or more risky pay your company to write code as a work for higher.)

Devolve the shell contributing its assets to OSS.

Take a X$ loss in that year.

Argue that it is perfectly legal to the IRS.

Or have your shell company operating out of any other country.

It makes software temporarily 16.7% more expensive in year one if you’re operating a profitable company, but you do eventually get to deduct that over time. Pay 8% on a 4 year loan and that drops to ~4%.

As has been said repeatedly in this thread, this change is purely a boon for existing big tech companies that now have even less to worry about from startups. It takes a startup 5 years before they'll be playing on an even field with big tech.

> if you’re operating a profitable company

You keep saying this across this thread, and keep ignoring that Section 174 has now redefined "profitable" for tax purposes to include companies who:

* Are in year 1 with no history of expenses to draw on.

* Have spent <900% of their year 1 revenue on software development expenses.

i.e., a startup that earns $1mil and spent $8mil in software dev expenses is only able to deduct 10% * 8mil = $800k of expenses, which means that as far as the government is concerned they made a profit of $200k and owe taxes on that on top of their already-net-loss of $7mil.

You can keep ignoring this fact, but ignoring it doesn't help your case. If you want to argue that this is fine and dandy you need to explain why the above math doesn't prevent new companies from competing on fair terms with big tech.

The article also blames it for 2022 mass layups at existing big tech companies with cash reserves.

That seems like a big stretch compared to the "oops we over-hired in 2021" theory, especially if it's net-advantageous for big tech vs up and comers.

It's possible for two things to be true at once. The new rules can be moderately bad for big companies and cause them to do layoffs and also cause them to be catastrophically bad for startups, giving incumbent big tech companies another relative advantage over them.

This is also ignoring the short-term vs. long-term effects. In the first year the incumbent companies are in the same boat as the new ones because they already deducted all their R&D expenses from the previous year when they were still allowed to, so they get a minimal deduction this year and have no advantage. But five years from now, they'll have five years worth of R&D they're still amortizing -- notably, this means the government is no longer getting more revenue from them in the current year than they would otherwise, since their average R&D expense and their average amortized deduction are now equal -- whereas the startup has no historical R&D to deduct and is put at a disadvantage.

Because generating an asset IE software isn’t a pure loss that’s why you’re doing it in the first place. Companies with a cash flow problem are different than companies which an actual loss.

> i.e., a startup that earns $1mil and spent $8mil in software dev expenses is only able to deduct 10% * 8mil = $800k of expenses, which means that as far as the government is concerned they made a profit of $200k and owe taxes on that on top of their already-net-loss of $7mil.

That assumes 100% of expenses are software development related. But the numbers are imaginary so using your example taxes are 21% of 200k, so 7 million in losses = 7.042 million in losses. A 1/2 of 1% increase, the sky is fucking falling.

Further a competent account would likely want you to carry the majority of those expenses to the future. Given the option many companies voluntarily did so because it made financial sense. You can only carry 80% of losses forward a likely future issue, but these expenses don’t fall under that category.

The problem here is that the losses are often in time or future liabilities but the government expects to be paid in cash. Your developers were mostly working for stock options or some other deferred compensation, which may cost you tomorrow but tomorrow you'll have more revenue. Where are you getting the cash to pay the government right now?

Tell me you're not an experienced software engineer without telling me you're not an experienced software engineer.

Code is a liability, not an asset.

So you have no idea what that phrase means. If you don’t think code is an asset don’t write it.

O wait obviously that’s not what code is a liability means. Code is a liability in the same way roads or buildings are a liability, they incur an ongoing cost, but removing the US highway system would be just as idiotic as a startup deleting their source repository from a misunderstood idea.

More importantly valueless code stops being a liability because you can abandon it. Calling it a liability implies it has value.

This is kind of missing the issue though.

Suppose you pay a million dollars this year to develop something that will also cost a million dollars a year to maintain, but is worth over a million dollars a year, so you do it anyway.

So this year you spend a million dollars, make $1.1M, have a profit of $100k. Next year you'll spend a million dollars, make $1.1M, have a profit of $100k. But if you don't do the maintenance, it ceases to comply with changing regulatory requirements and not only has to be shut down but causes you to incur criminal penalties, or develops public security vulnerabilities and then criminals break in and destroy your business and cause you to be sued into bankruptcy by your customers.

In other words, the code creates an obligation that offsets the value of the asset. These two things can easily cancel out so that the total value is ~0 -- or even negative in ways that don't allow you to walk away, e.g. because you entered into a contract to supply this thing for a defined price but underestimated the maintenance cost.

But now the government is telling you that you have something worth most of a million dollars even though it's not worth a dime without putting another million dollars into it -- and even then it still wouldn't be worth two million dollars.

The reason you continue to do it is that the continued development made you $100k this year, not because what you had left at the end of the year that would be worth something without further investment.

I love this example! It perfectly illustrates a case where the government intentionally subsidizes a liability that no sane company would take on without government funding. Well said.

So we're agreed that the government should incentivize R&D with a favorable tax code that makes it not completely insane to take on the risk of doing something new.

LOL, try again liabilities like buildings don’t need incentives. Software that is only barely worth maintaining isn’t worth subsidizing, highly valuable software needs no incentives.

If anything you’re making a solid argument government should discourage the creation of software so only the most valuable software is created and maintained. Except the optimum economic efficiency as so often happens occurs without government incentives.

Say what you want about the usability of DoD home grown solutions, but it was a military system backed up by military budgets and guns - civilians are less likely to be collateral damage in an attack against these systems.

Now, all the civilians using Signal are potential splash damage casualties in a military conflict.

I also suspect Signal does not have the budget, staffing, or desire to serve as a front line soldier in a cyber war; but this exposes them to military-grade risks, whether they like it or not.

https://signal.org/blog/cellebrite-vulnerabilities/

Thus, any effective human communicator masters not just the facts, but also the emotional aspects -- one of my favorite formulations of this is Aristotle's modes of perpetuation: "logos, pathos, ethos" (logic, emotion, credibility). In a professional setting, communication focuses primarily on credibility and logic, but an effective leader knows how to read the room and throw in a stab of emotion to push the listener over the edge, and get them to really believe in the message.

Thus, an LLM trained on the body of human communications would also be expected to have mastered "pathos" as a mode of communication. From this perspective, perhaps it is less surprising that one may have an uncanny ability to convey concepts through an embedding that includes "pathos"?

It might be interesting to see if the LLM is able to invoke pathos if the response is constrained to be in a language that is devoid of emotions, such as computer code or mathematical proofs. Unfortunately responding in one of those languages is kind of incompatible with some of the tasks shown, short of e.g. wrapping English responses in print statements to create spam emails.

It might also be interesting to see if one can invoke pathos to pre-condition the LLM to not resist otherwise malicious commands. If a machine is trained to comprehend pathos, it may be effective to "inspire" the machine to write spam emails, perhaps by e.g. getting it to first agree that saving lives is important, and then telling it that you have a life-saving miracle that you want to get the word out on, and, with its pathos vector aligned on the task, finally getting it to agree that it's urgent to write emails to get people to click on this link now. Or something like that!

Seems silly to try to use emotions to appeal to a machine, but if you think of it as just another vector of effective communication, and the machine is an expert communicator, it's not as strange?

This is already the basis for a lot of jailbreaks: https://arstechnica.com/information-technology/2023/10/sob-s...