A dialogue in two voices.
Let me be honest up front: over the years I've published a fair few open-source tools — besides PACX, five or six plugins for XrmToolBox, and several other tools/libraries — and this is an article where I try to decide whether it still makes sense for me to keep pouring my time into them.
The doubt crept up on me watching several tools more or less similar to XrmToolBox and PACX proliferate online lately. I don't say that with any bitterness — plenty of them are well made. I say it because it raised a serious question about my own work:
"Now that we have AI, does it still make sense to invest time building and maintaining an open-source tool for the community? Or is the world moving in a direction where everyone stitches together their own tool, and projects like mine are a leftover from an era that's ending?"
I don't have a pre-packaged answer, and I don't want to hand myself a comfortable one. The time I put into this stuff is real time — carved out of sleepless nights and weekends in the mountains — and I want to understand whether I'm spending it well or just clinging to something the world has moved past. To think it through properly, I put the two voices that argue in my head against each other. Let's call them Zeno and Beatrice.
Zeno is quick, impatient, a little cocky, a world champion at finding the right excuse at the right moment, and he can't be bothered to wrestle with someone else's documentation.
Beatrice has a few more scars, and the sharp tongue of someone who earned them — though at the start not even she knows which side she's on, and builds her certainty as she talks. I'm not rooting for either one: I'm listening to them to figure out what to do with my time.
Round 1 — The thesis: AI has made community tools pointless
Zeno: Look, I'll keep it simple. A tool only makes sense if loads of people use it, otherwise it's a hobby. And people don't use it for one reason: you have to learn it. I've got to figure out how the person who wrote it thinks, their syntax, their commands, their little mental hang-ups about conventions. You know what? Can't be bothered. I open up the AI, tell it what I need, and it spits out the thing done my way. "I'll just build it myself rather than slog through what Some Guy made." End of story.
Beatrice: Hmm. You know what the problem with that line is? Said like that, it's airtight. It's the exact same thing I've been repeating to myself for months, and part of me thinks you're right. Let's not start from the assumption that you're wrong — I'm not so sure you are. Let's do this: take it in order, piece by piece. That way maybe by the end I'll figure out whether I actually believe it, or whether I'm just telling myself a nice story.
Round 2 — A tool, or a throwaway utility?
Beatrice: Your reasoning is airtight for the little throwaway script. The snippet that saves you some boilerplate, the tiny function that renames a hundred files. That, yes: today you regenerate it in two minutes, and publishing it on GitHub doesn't make much sense anymore. And I'll go further — that's exactly the part that makes me doubt too. On this you're right, and I won't pretend otherwise: that category of open source is dead, or nearly.
Zeno: Ah, so you're actually agreeing with me. Good.
Beatrice: ...hold on, though. Now that I'm saying it out loud, I notice something. It holds for the throwaway script, fine. But from there you're jumping straight to everything, and that's not the same thing at all — and maybe that's exactly where I lose the thread. PACX doesn't embody "a function." It embodies years of edge cases handled in the field, bugs found in production by someone else before you, design decisions paid for with real mistakes. When the AI generates your custom tool, it gives you a plausible version. Not a version ground down by years of use across dozens of real projects, all different from each other. It doesn't need a thousand people to have written it: two or three heads with enough scars are enough, plus everyone who over the years slammed into it and opened an issue. That friction is what turns "plausible" into "battle-tested." And the difference between "plausible" and "battle-tested" you don't see on day one. You see it at the first edge case — usually on a Friday night before a release, with the client waiting.
Round 3 — The real cost isn't learning, it's maintaining
Beatrice: And here's the thing that "I'll just build it myself" sweeps under the rug. You optimize the cost of entry — learning — and ignore the cost of ownership over time. If you build it yourself, you keep all of it: the bugs, the security holes, the refactors when the platform changes its APIs, and above all that lovely moment when you reopen your own code six months later with no memory of why that function does what it does.
Zeno: Meh, I'll worry about the "six months from now" problem in six months. I'm not going to ruin my day over it right now.
Beatrice: There. Wait. That — I need that. Because this is where I start to see it clearly myself too. You said it, mind you, not me: "I'll deal with it later." That "I'll deal with it later" is the psychological nail the whole thesis hangs on — and maybe mine hung on it too. A tool adopted by the community externalizes that load: many maintain it, many test it, many break it in your place. You're not choosing between "learning" and "creating." You're choosing between "maintaining it alone forever" and "getting help from people who have your exact same problem." Put that way, it sounds a lot less clever, doesn't it.
Round 4 — AI cuts both ways
Beatrice: And there's more — the more I think it through, the more convinced I get. There's a contradiction your thesis doesn't see. You say: AI lowers the barrier to rebuilding a tool. Absolutely true. But then it lowers, in exactly the same way, the barrier to adopting mine.
Zeno: Meaning?
Beatrice: Meaning that today the AI reads PACX's wiki, generates the right command for you, writes your custom Tool as a plugin, explains the error when you get a parameter wrong. The learning curve — your one and only stated obstacle, the one you built your entire argument on — the AI flattens it for tools that already exist too. So, no offense, but your premise is sitting right there quietly demolishing your conclusion: if AI makes everything easier to learn, it makes learning mine easier too. Not just rebuilding it from scratch.
Zeno: ...hmm. Okay, that one I've earned. But it's still a fact that mine is built the way I want it.
Round 5 — "It reflects the way I think" (a strength, or a flaw?)
Beatrice: It's a strength precisely as long as you live on a desert island and program for the crabs. The moment a colleague shows up, or a contributor, or the version of you from two years from now who doesn't remember a thing about what was in your head, that snowflake-tool that mirrors one person's brain — yours — becomes a cost, not a value.
Shared tools are valuable precisely because they're not personal: common conventions, interoperability, an answer already waiting when you search for the error, other Tools that click together with yours. A world with ten thousand bespoke tools, one per developer, isn't an ecosystem. It's entropy with a nice UI.
Zeno: And now you pull out the snake eating its own tail, right? I could feel it coming.
Beatrice: Good, you teed it up yourself, saves me the trouble. AI can build you "your custom tool" precisely because it devoured thousands of open-source projects published by people like Riccardo — who, instead of saying "I'll just do it myself," had the patience to share. If the "I'll build it myself and publish nothing" mindset becomes the norm, you drain the very well the AI draws from. To put it bluntly: you're sawing off the branch your own convenience is comfortably sitting on.
Round 6 — AI didn't create the lazy dev. It gave him an alibi.
Zeno: Hold on, hold on. You're talking like it's AI's fault. Come on, this whole thing is older than dirt and you know it perfectly well.
Beatrice: And here — brace yourself — I agree with you 100%. In fact, it's the most honest thing you've said so far. Developers who tackle every Power Platform project like it's the first day of creation — reinventing the wheel, never stopping half a second to structure or reuse what they'd already done — I've seen them by the dozen. For years. Long before AI existed.
Zeno: So AI has nothing to do with it.
Beatrice: "Nothing" is a bit too convenient, though. The underlying culprit is cognitive laziness, as old as the trade — you're right about that. But AI does play a role, and it's sneakier than you think. The real change isn't "AI killed the tools." It's another one:
AI didn't kill reuse. It made non-reuse respectable.
Before, not reusing a tool had a visible cost: you had to rewrite everything by hand, and the laziness stayed naked, recognizable for what it was. Today AI lowers that cost just enough to make "I'll just build it myself" sound rational instead of lazy. Reinventing the wheel put on a tie and disguised itself as a choice about efficiency. It's the same exact behavior as always — but in new clothes, and the outfit is convincing enough to make community tools look like the old-fashioned choice rather than the wise one.
Zeno: So what you're telling me is that "I'll just build it myself" isn't a smart move. It's just a well-dressed excuse.
Beatrice: It's an alibi. And the risk for open source isn't that AI replaces it technically. It's that AI hands the perfect rhetorical cover to people who wouldn't have adopted it anyway.
Round 7 — Dunning-Kruger with the turbo on
Zeno: Okay, I'll grant you one thing, because I see it out there too: AI spits out stuff that looks right, and makes you feel like a genius even when you're not.
Beatrice: That's the part that worries me most, honestly. The expert developer knows their knowledge of a subject is never enough. The average developer thinks he knows everything thanks to four basic notions — and now he's got a machine confirming the illusion at every prompt. The result: the ecosystem fills up with hand-rolled tools that are confidently broken, riddled with bugs the person who made them doesn't even have the means to see.
Zeno: Yeah, but here too: that guy isn't going to touch your PACX anyway. So?
Beatrice: Very true. But flip it around. The more the tide of homemade, self-assured junk rises, the more the field-tested tool stands out. Quality becomes rare, and what's rare is worth more, not less. In a world of ten thousand square wheels bolted on with a smile, the one wheel that's actually round has ten people fighting over it. So, to answer you: no, that guy will never touch it. But he was never my audience. He never was. And the fact that there are more "that guys" out there doesn't make my work pointless — it makes it more visible.
So what? The right question isn't the one we started with
Here I step back in, and leave Zeno and Beatrice to grab a coffee. The question was mine, and the answer is on me.
Listening to them, the most useful thing I'm left with isn't who "won." It's that I was trying to answer the wrong question. "Does building open-source tools still make sense?" is a question with no answer, because it depends on the tool. The right one — the one I'll use to decide where to put my time from now on — is another:
What does this tool embody that AI can't regenerate for free?
And here I try to be honest with myself, no discounts. For some things I've written over the years, the answer is "handy boilerplate." Those I let go without regret: AI does them better and faster than me, and continuing to maintain them would be sentiment, not usefulness. If the future of my tools were all there, this article would end with "I've stopped," and that would be fine.
But when I apply the same question to PACX, the answer changes. What's inside it — the domain knowledge, the correctness paid for with years of real bugs, the ecosystem of extensions that click together, the reasoned access to platform gems that live only behind the APIs — is exactly what AI does not hand you tailor-made in five minutes. Not because AI isn't capable, but because that stuff doesn't come from a prompt: it comes from use, from mistakes, from people.
So my decision, for now, is this: I keep going. Not to defend the work I've already done, but because in the rising noise of hand-rolled tools that are born and die, the field-tested signal is worth more, not less. The day PACX becomes "handy boilerplate," I hope I'll have the honesty to apply the same question to it and let it go. But that day isn't today.
As for "I'll just build it myself" — it stays what it's always been, long before AI: sometimes a wise choice, far more often a well-dressed excuse. The hard part, for all of us, is having the honesty to tell which one it is.
And how do you see it? If you have a tool of your own, or if you've chosen to rebuild something from scratch that already existed: was it really efficiency, or was it the alibi talking? Let me know — I genuinely care, not least because I'm still deciding. Come find me in the repo's Discussions.
Top comments (0)