Customers will have to absorb a little pain
(install Mono or .NET, new version teething
pains) in exchange for a little sugar (nice new
features). I guess I’d have to balance the work
effort vs. the sales upside of a new,
rearchitected version of FogBugz.
I’m sorry, but that is much worse than the solution implemented by Joel. Have you tried FogBugz under windows? You just run an installer. That’s it. And, why, oh GOD why, do you want a new “rearchitected” version of FogBugz?
we could conceivably move to .NET by using the
Wasabi compiler to generate C#, and require our
customers to install Mono on Unix. (Still
requires Wasabi, but we would throw it away when
we were done with the last step).
I’ve heard mono’s UNIX support for C# and
ASP.NET is quite good.
So, you don’t really know.
Again, it’s your business. Not mine. But I think
that’s clearly the way to go. You’ll probably
have to refactor a lot of the generated C# code
to get it to look like code human beings would
write (or even a traditional ASP.NET app; not
sure if that’s a goal or even desirable in these
circumstances). But that’s still a heck of a
lot less work than a total rewrite in another
language. Which, based on the contents of your
prior posts, I’m 99.9% sure you would never
approve anyway.
But, why do you insist in a total rewrite? I really don’t understand that fixation in rewriting a perfectly good, working, revenue generating application.
At least with C#, new programmers’ heads are a
lot less likely to explode while working on
FogBugz. It might also open up some
extensibility points for community-written C#
plugins, etcetera.
Who are this programmers you are talking about? FogBugz users? They don’t need to modify anything, except one or two reports, and those are written either in PHP or VBScript. I’ve never heard of anybody’s head exploding for using them.
Anyways, I always enjoy your writings, but this time I think you haven’t quite understood the business decision made by Joel.