The .NET ecosystem has long been a staple of enterprise development, but lately, the mood in the community feels… uneasy. From rumblings on social media to open letters and flamey blog posts, developers are starting to ask tough questions: 

Is .NET losing its soul? Is it still a welcoming place for open-source contributors? And is the community that built so many of its best tools now being left behind? 

In Episode 42 of The Beer Driven Devs, we tried to unpack all of this. Here’s the gist. 

The IdentityServer “rug pull”

When IdentityServer, once the de facto standard for .NET auth, moved to a commercial license, many developers felt blindsided. But was the surprise truly about Duende’s decision, or Microsoft’s role in setting expectations? 

Microsoft had included IdentityServer in the official .NET templates, effectively promoting it as the default approach to authentication and authorisation. For many developers, especially those newer to the ecosystem, this created an implicit assumption: if it’s in the box, it must be both official and free. 

When Duende took IdentityServer commercial, the shift was understandable, driven by sustainability and resource constraints, but the messaging around that shift lacked coordination with Microsoft. Developers were left scrambling to decide whether to pay, replace, or reinvent a critical piece of their application’s infrastructure. 

Should Microsoft have offered clearer transition guidance or better alternatives? It’s a fair question. Some have pointed to Entra ID (formerly Azure AD) as a possible migration path. It’s free up to a point and doesn’t have the monthly active user (MAU) limitations of Azure AD B2C. But it lacks the customisation and flexibility that made IdentityServer so appealing in the first place. 

.NET 8 introduced new Identity endpoints, but they’ve been met with cautious optimism at best. Community sentiment remains mixed, especially when it comes to using them in commercial or production-grade applications where fine-grained control is non-negotiable. And, not being OIDC, they require custom client code. 

The IdentityServer situation ultimately raises a deeper issue: when platform maintainers endorse third-party tools, especially in templates, they bear some responsibility for the ecosystem impact if those tools pivot or vanish. Without coordinated support or communication, developers are left holding the bag. 

April’s One-Two Punch 

More recently, Jimmy Bogard announced that Automapper and MediatR would adopt a commercial model. Again, it triggered a wave of reactions – from “finally, good for him” to “this is the end of OSS in .NET.” 

The truth? It’s complicated. Many of these tools have been running on goodwill for years. But their commercialisation raises questions: 

• Should maintainers feel obligated to keep things free? 

• What responsibility does Microsoft have, given how heavily they rely on these tools? 

• Is it even possible to build sustainable open source in .NET without eventually burning out? (We’ll look at this a bit further down).  

And then, on the very same day, MassTransit announced its own shift toward a commercial model. The timing was so coincidental that their team had to include an FAQ in their blog post: “Did you coordinate this announcement with Jimmy?” (They didn’t.) 

But the fact that this question even needed asking highlights the broader reality: this isn’t an isolated incident. It’s a pattern. A wave of seasoned maintainers reaching a breaking point all at once. 

To the community, it feels like a collective tipping point, where years of unpaid labour, rising expectations, and limited support finally became untenable. 

Not All OSS Is Created Equal 

IdentityServer, MediatR, and MassTransit aren’t isolated cases. But they hit harder than most, and there’s a reason for that. Not all open-source software is created equal. 

Some tools are simply “nice to have.” Others are mission-critical. Some are trivial to recreate. Others would take months, if not years, of specialised effort. And some, like identity and messaging platforms, are so complex and security-sensitive that recreating them in-house is simply off the table. 

It’s in this crossover – high usefulness, high complexity – that projects become indispensable. They represent the sweet spot of OSS vulnerability: too essential to abandon, too specialised to rewrite, and now, no longer free. 

We’ve seen similar forks in the road with tools like Prism or ReactiveUI, and other OSS libraries that have either slowed development or quietly shifted toward closed-source equivalents. 

At the same time, projects like Serilog and FluentValidation continue to thrive with strong community support and thoughtful stewardship. These examples show sustainability is possible; but rarely accidental. 

Can Going Commercial Work for OSS? 

While much of this discussion has focused on the risks and fallout of open-source projects going commercial, it’s worth recognising that this shift isn’t always negative. In fact, there are plenty of success stories: 

• Redis Inc. transformed Redis into a powerful commercial product while maintaining widespread usage. 

• HashiCorp re-licensed Terraform and Vault under a more restrictive model and remains dominant in the infrastructure-as-code space. (That said, the OpenTofu fork is gaining traction, and it’s shaping up to mirror LibreOffice, where the fork may eventually become the de-facto community standard). 

• GitLab built a sustainable open-core model and went public. 

• Elastic moved Elasticsearch to a more protective license, sparking a fork but continuing as a strong commercial player. 

• JetBrains has long offered paid versions of their tools alongside free editions, funding continuous innovation. In fact, in contrast to other recent developments, JetBrains have recently announced a community edition of their popular .NET IDE Rider. 

These stories offer an important counterpoint: commercialisation can be done ethically and sustainably. The key is clarity, communication, and respect for the community that got the project there in the first place. 

What Are the Paths to OSS Sustainability? 

Does every product need to go down the commercial path though? Or is there a way for open-source projects to thrive as they reach (and surpass) critical mass? There’s no single right answer, but some models include: 

• Consulting and training: Offering paid expertise around the tool you built. Note that this doesn’t always work – the maintainers of IdentityServer did this for a time before taking the product commercial, but it didn’t provide enough revenue to sustain the product. 

• Open-core or dual licensing: Free base, paid extras. This can and does work well in many cases. The aforementioned JetBrains or GitLab both adopted this model. 

• Sponsorships and donations: Many open-source projects are sustained though this model. Think GitHub Sponsors, Patreon, Open Collective. 

• Paid support tiers: The poster child for open-source commercialisation may be Canonical. They offer the extremely popular Ubuntu in both desktop and server versions, free of charge, for personal, education, or commercial use (or any use; but without warranty). Their revenue comes from paid support, offering SLAs, bug triage, or feature prioritisation. 

These all come with trade-offs, and not every project or maintainer wants to become a business. But ignoring the question of sustainability leads us to burnout; or worse, abandonment. 

What Do OSS Maintainers Owe the Community? 

Maintainers often feel pressure to be everything: engineers, community managers, tech support, and sometimes unpaid therapists. But it’s worth clarifying what they do, and don’t, owe us: 

They do owe: 

• Honest communication 

• Clear licensing and expectations 

• Respectful, inclusive community spaces 

They don’t owe: 

• 24/7 support 

• Free labour for commercial companies 

• A lifetime of maintenance on a tool they built for fun 

If you’re curious to hear more, we covered this in a past episode: What does open source owe you? 

What Do Large Enterprises Owe OSS? 

Let’s flip the question. What do consumers of open source owe in return? Especially when those consumers are billion-dollar companies. 

There’s both a moral and a practical case to answer: 

Ethically: If your profits depend on free tools, contributing back – financially or with code – isn’t generous, it’s fair. 

Practically: Without support, tools stagnate, break, or disappear. The cost of doing nothing today is paying for a rewrite tomorrow. 

Some concrete ways companies can give back: 

• Pay maintainers or sponsor key projects 

• Encourage contributions on company time 

• Open-source internal tools that might benefit others 

• Hire developers who maintain open-source projects 

Is .NET Becoming Too Enterprisey Again? 

There’s a creeping fear that .NET is returning to its old image: a closed, Microsoft-centric, enterprise-only ecosystem. But this concern goes deeper than nostalgia – it points to an existential risk. 

The .NET Framework era was dominated by expensive tooling, MSDN subscriptions, and a commercial-first mindset that limited access to well-funded enterprises. When .NET Core arrived, it signalled a cultural shift: open source, cross-platform, and developer-friendly. Combined with Satya Nadella’s leadership and Microsoft’s newfound OSS credibility, the platform experienced a renaissance. 

But the landscape has changed. Today, developers have real choices – Go, Rust, Python, JavaScript, and Java all offer robust, open-source ecosystems with growing enterprise adoption. If .NET slides backward into an enterprise-only posture, it won’t just alienate individual devs, it will become uncompetitive. Startups won’t touch it. CS students won’t learn it. Bootcamps won’t teach it. And enterprises, even with deep pockets, will follow the talent elsewhere. 

And here’s the kicker: .NET isn’t the moneymaker it once was. Azure is Microsoft’s true revenue engine, and Azure supports all of those other languages and frameworks just as comfortably. There’s no business imperative for Microsoft to save .NET OSS from decline. If it’s going to thrive, it has to do so on community strength and real-world value. 

So… What can we do? 

If .NET is going to thrive as an open, healthy ecosystem, it won’t be because someone at Microsoft flips a switch. It’ll be because we, the community, kept it alive. 

So what can we do? 

Support the projects we rely on – financially, or with contributions, advocacy, or simple gratitude 
Talk openly about licensing, sustainability, and burnout – normalise these as real, valid concerns 
Be intentional about the tools we choose – don’t just grab what’s popular or pre-installed; ask who’s maintaining it and how 
Amplify OSS voices – especially when they’re calling for help, change, or recognition 
Push our employers to give back – through sponsorships, contributions, or simply allowing OSS work on company time 

We can’t solve every structural challenge, but we can make different choices. And if enough of us do, the centre might just hold. 

And maybe, more open conversations like this one. 

A Bigger Picture: The Cost of Free Software 

If you want a more profound, articulate, and frankly, better-argued take on this whole topic, I highly recommend Dylan Beattie’s talk: The Cost of Free Software. 

He dives deep into the economic, cultural, and emotional realities of building software for free, and why so much of the modern internet is running on good intentions. 

Join the Conversation 

We’re considering hosting a live panel or community meetup to go deeper on these issues. If you’re a maintainer, contributor, or .NET die-hard, we want to hear from you. 

Drop us a message, share this post, or listen to the full episode to join the conversation. 

Alright, web developers. Today, we’re stepping into the ring to watch htmx go toe-to-toe with the big players: React, Vue, and Angular. But this isn’t a deathmatch. It’s about finding the right tool for the right job. Let’s get into it.

What’s the Difference?

JavaScript frameworks like React, Vue, and Angular are designed for building full-blown client-side applications. They offer:

• State Management: Fancy mechanisms for handling complex data structures.
• Routing: Single Page Applications (SPAs) that update the view without refreshing.
• Component-Based Architecture: Reusable building blocks to keep code organized.

But here’s the catch. They’re also:

• Heavy: Your users have to download and parse tons of JavaScript.
• Complex: State management, hooks, virtual DOM, build tools – it’s a lot.
• Overkill for Simple Use Cases: Sometimes, you just need a form to submit asynchronously.

Where htmx Fits In

htmx is built for situations where you want interactivity without the baggage. It’s simple, small, and doesn’t require a mountain of tooling.

Comparing htmx with React, Vue, and Angular

Feature	htmx	React / Vue / Angular
Learning Curve	Super Low	Moderate to High
Bundle Size	~10KB	Hundreds of KBs
Server-Side Rendering	Built-In	Requires Setup
State Management	Handled by Server	Requires Client-Side Solutions
Use Cases	CRUD, Forms, Dashboards	SPAs, Rich UI, Complex Apps

Scenarios Where htmx Shines

Let’s be real. If you’re building something like Facebook, you’re going to need a heavy-duty JavaScript framework. But most of us aren’t building Facebook. So, when is htmx the better choice?

1. Basic CRUD Applications

If your app is mostly about retrieving, updating, and displaying data, htmx is a great fit. No need to ship a bloated front-end library just to create a To-Do List or a simple blog.

2. Server-Rendered Apps

ASP.NET Core developers are already used to building apps with server-side rendering. htmx lets you keep most of your logic on the server, where C# is your best friend.

3. Incremental Upgrades

Have an existing app that needs a little interactivity? You can sprinkle htmx over your existing HTML without having to rewrite your entire frontend.

Example: Editing a List of Items

Imagine you have a list of items you want to edit in place.

Index.cshtml

@page
@model IndexModel

<!DOCTYPE html>
<html>
<head>
    <title>Editing Items with htmx</title>
    <script src="https://unpkg.com/htmx.org"></script>
</head>
<body>
    <h1>Item List</h1>

    <div id="item-list">
        @foreach (var item in Model.Items)
        {
            <div id="item-@item.Id">
                <span>@item.Name</span>
                <button hx-get="/EditItem?id=@item.Id" hx-target="#item-@item.Id">Edit</button>
            </div>
        }
    </div>
</body>
</html>

Index.cshtml.cs

using Microsoft.AspNetCore.Mvc;
using Microsoft.AspNetCore.Mvc.RazorPages;
using System.Collections.Generic;
using System.Linq;

namespace YourNamespace.Pages;

public class IndexModel : PageModel
{
    public List<Item> Items { get; set; } = new() {
        new Item { Id = 1, Name = "Item One" },
        new Item { Id = 2, Name = "Item Two" }
    };

    public IActionResult OnGetEditItem(int id)
    {
        var item = Items.FirstOrDefault(i => i.Id == id);
        if (item == null) return NotFound();

        var editForm = $"<form hx-put='/UpdateItem' hx-target='#item-{item.Id}'>" +
                       $"<input type='hidden' name='Id' value='{item.Id}' />" +
                       $"<input type='text' name='Name' value='{item.Name}' />" +
                       "<button type='submit'>Save</button>" +
                       "</form>";
        return Content(editForm, "text/html");
    }

    public IActionResult OnPutUpdateItem(int id, string name)
    {
        var item = Items.FirstOrDefault(i => i.Id == id);
        if (item == null) return NotFound();

        item.Name = name;
        return Content($"<div id='item-{item.Id}'><span>{item.Name}</span> " +
                       $"<button hx-get='/EditItem?id={item.Id}' hx-target='#item-{item.Id}'>Edit</button></div>", "text/html");
    }

    public class Item
    {
        public int Id { get; set; }
        public string Name { get; set; }
    }
}

Mixing htmx with JavaScript Frameworks

Okay, so what if you want the simplicity of htmx but you also need a fancy component here and there? Easy. You can use HTMX for most of your application and sprinkle in something like Vue or React where it makes sense.

Hybrid Approach Example

You can use htmx for most of your application, but when you need more complex UI elements, you can use a React component.

<div id="react-component"></div>
<script src="/dist/YourReactComponent.js"></script>

Your React component can live on the same page, and you don’t have to go full SPA mode.

The Bottom Line

If you need blazing fast interactivity without the hassle of setting up a complex front-end stack, htmx is a fantastic choice. It’s not here to replace React, Vue, or Angular. Instead, it offers a simpler, more efficient way to build apps when you don’t need the heavy artillery.

Stick around, because next time, we’ll dive into more practical use cases and how to make the most of htmx in your ASP.NET Core applications.

The post htmx vs. JavaScript Frameworks: Choosing the Right Tool for the Job appeared first on Chris Woody Woodruff.

China has responded to Donald Trump’s new trade tariffs with its own charges on US imports. After Trump announced the imposition of an additional 34 percent charge on Chinese imports into the US, China has announced a levy at the same rate for US goods shipped to China.

In a statement announcing the new tariff, China’s finance ministry declared that the US tariff on Chinese goods “seriously undermines China’s legitimate rights and interests,” and called it a “typical unilateral bullying practice.”

“China urges the United States to immediately cancel its unilateral tariff measures and resolve trade differences through consultation in an equal, respectful and mutually beneficial manner,” the statement concludes.

The Chinese levy will go into effect on April 10th, one day after the US’s new tariff starts to apply. According to The New York Times, China has also imposed strict limits on the exports of some rare earth elements that are mined almost exclusively in China, used in electric vehicles, weapons, and other tech.

The country has also barred 11 American businesses from importing to or exporting from China, adding them to its “Unreliable Entity List.” The list, mostly made up of drone and defense companies, includes enterprise drone manufacturer Skydio.

The BBC reports that China has also filed a lawsuit with the World Trade Organization (WTO), which follows a dispute complaint it lodged with the organization in early February following Trump’s previous tariffs on the country.

Developing…

If you were wondering how President Trump’s tariffs may impact gadgets like smartphones, laptops, and smartwatches, there’s some bad, and perhaps slightly less-bad news. Unless something changes, Trump’s sweeping tariffs will lead to increased prices for consumers. But it will likely take some time before that actually happens.

Modern gadgets generally aren’t made or assembled solely in the U.S. anymore. Device makers big and small source components from all over the world, and often have them assembled overseas before importing the final product into the country. Given that Trump has levied tariffs on every single country, it means that the cost to make all our devices will inevitably go up.

“The biggest thing right now is going to be the inflationary impact,” says Jason Miller, professor of supply chain management at Michigan State University. “If they stay in place for several months, we’ll start to see those effects by mid-summer and certainly back-to-school season.”

Miller notes goods shipped from China to the U.S. will face a whopping 54 percent tariffs, including most gadgets. Vietnam, where Apple has shifted some of its manufacturing, also has a high …

Read the full story at The Verge.

Cognition, the startup behind the viral AI programming tool Devin, has introduced a new low-cost plan to incentivize signups. When Cognition released Devin last year, the tool quickly blew up on social media for its ability to perform certain software development tasks autonomously. But it soon became apparent that Devin struggled with more complex coding […]

If you own a reMarkable tablet, this update just made your digital notebook a whole lot more useful.