How are they supposed to fund development? It's important to differentiate independent devs and the goliaths. When you release an app like this, it is "good enough" for more people. Your incentive to build the thing is that you can make a living off of it and continue crafting it with the intent of building other great things. The biggest software companies have many revenue streams and ways to cover costs that are very different from independent devs.

When you sell perpetual use software, you have the incentive to release yearly versions (or whatever cadence is best.) You are incentivized to only put bugfixes into next year's version to force upgrades. Users lose out because they don't get bug fixes and the developer is put in a spot where they have to look for more devious ways of making a profit.

To make money the cost of perpetual software is also very high. Devs make terrible compromises here to seem reasonable, but you need to move a lot of units to reduce the price to the level possible with subscription software.

Subscriptions are far from perfect, but they bring some balance. Next time you complain, it would be an interesting exercise to state what you would be prepared to pay and how often.

Windows was really picking up steam and there was a move to web development in the Windows-based developer space. Visual Basic and Delphi were popular but desktop development had peaked. ASP was for building your apps and SQL Server was the natural backend. SQL Server fed off this wave. It wasn't dislodging Oracle, but rather than every app being built on Oracle, more apps started to use SQL Server as the backend.

Then ASP.NET appeared on the scene and demand grew even more. It was a well-integrated combo that appealed to a lot of shops. I started my career in a global pharma and there was a split between tech budget. IT was a Windows shop for many reasons and ran as much on SQL Server as possible. R&D was Unix/Linux with Oracle. There was a real battle going on in the .NET vs Java (how about some EJB 1) and the databases followed the growth curves of both rather than competing against each other.

The SQL Slammer worm brought a lot of attention to the product. There were instances running everywhere and IT didn't expect so much adoption. Back then you had a lot more servers running inside offices than you do today. My office was much like my homelab today. This validated the need so the patches got applies, IT got involved in the upkeep, and adoption continued to grow.

Oracle's sales folk and lawyers were horrible to deal with. I had some experience of this directly as they tried pushing Java-related products and my boss dragged me into the evals. One of my in-laws was outside counsel in the IT space doing work with enterprise-sized companies. He claims they are the worst company he's ever had to deal with and wouldn't delegate any decision-making locally which endlessly dragged out deals. They had a good product but felt they could get away with anything. Over time he saw customers run lots of taskforces to chip away Oracle usage. This accelerated with SaaS because you could eliminate the app AND Oracle in one swoop.

People have a superficial knowledge of the space (I think this extends beyond Codeberg) but feel strongly that they need to advocate for something. Codeberg themselves seem to have opinions about what they want to do but people are suggesting they can do more simply because it gives them an outlet.

The constraints that Codeberg set seem to, on the surface at least, ensure they can scale based on their needs and protect them from external threats. Hosting random sites comes with a range of liabilities they probably understand and want to avoid right now. There are EU regulations which can be challenging to handle.

I think you miss the more common reasoning though. This starts with "can we build a Windows app?" The answer to that was "no" for many more people until relatively recently. The .NET Framework wasn't as available by default until the second half of the 2000s which caused some Windows app devs to hold off beyond the performance reasons and WinForms vs WPF. Electron and React go hand-in-hand here as they made a (crappy) Windows app easy.

What I feel popularized this was the webview approach on mobile. In 2010, there were a ton of frameworks popping up for hybrid mobile development. This was carried forward to desktop although some of us had been embedding IE webviews much earlier. This let people say "yes" and it went from one thing to the next with diversions into React Native.

Kids already are well aware of iPhone upgrades. Parents will get them this machine. They'll get going and soon enough be badgering their parents for an upgrade to a more competent machine. That is all by design while being an affordance for people who can only get in at the cheap end.

It was a much bigger struggle with conversations where I was putting extra pressure on myself. Being able to have those other conversations was helpful though. Eventually, I found a therapist and am in a better place with this.

You expect the humans to follow laws, follow orders, apply ethics, look for opportunities, etc. That said, you very quickly have people circling the wagons and protecting the autonomy of JSOC when there is some problem. In my mind it's similar with AI because the point is serving someone. As soon as that power is undermined, they start to push back. Similarly, they aren't motivated to constrain their power on their own. It needs external forces.

edit: missed word.

Fast forward twelve years and my wife did the MCIT at UPenn (https://catalog.upenn.edu/graduate/programs/computer-informa...) where git and other topics woven into the curriculum. Even then, they were perhaps a novelty because their focus was bringing non-CS undergrads into a CS Masters program. So-called "conversion" master's degrees were the norm in the UK in 2002.

Similarly, a lot of the AGI-hype comments exist to expand the scope of the space. It's not real, but it helps to position products and win arguments based on hypotheticals.

They want a tool that makes this file share talk to this SharePoint site which updates this ERP tool over there. The LLM approach is great for the departmental person (if they can still host shadow IT) but falls down at the organizational level. The nature of this work is fundamentally different, crappier, and less interesting than what any person on HN wants to be doing which is a contributor to misunderstanding of the market.

EDIT: fixed grammar.

There is the expectation that the manager knows who will be distracted. This is a basic part of knowing your people. I know which of my colleagues is going to get distracted without having the level of communication that my manager has. On one extreme, they just forward information knowing a report can work with it. One the other, the manager has to translate and communicate every element.

Ideally, the manager is already working on a way to ensure their report can handle transparency because that means they can work autonomously. You can't have individual contributors lead, if they are going to run into issues as soon as they discover what is going on overhead. They may not understand it yet, but they should have coping and mitigation strategies.

Engineers can be the worst group you could deal with when it comes to overhead conversations when they expect things to be orderly. Your organization is failing when everything has to go through managers and people can't operate independently.

How would the economics of this work universally? Jetbrains is a bit of an oddity in terms of SaaS. For the most part, it's desktop or on-premises software that was sold with a perpetual license. If you've bought a subscription and canceled, they've generated some revenue. Maintaining a subscription generates more revenue for them, but they can slow or stop development without stopping you from using the product.

SaaS is typically some server software hosted by someone else which most often doesn't have an on-premises version. They can stop making feature updates, but if they turn off the servers, the service ends. They still have costs even if you use the software less. You can argue about the profit margins, but that's not the point here. As most SaaS companies don't start with on-premises, they can't ever get their software working there for many reasons. There are a few like Atlassian and GitHub that do both, but if you look at the heritage, both are really on-premises first.