As we near in on the Inkscape 0.46 release, I've been increasingly focusing on the few remaining "critical" bugs. A lot of these are specific to the Windows port, which is a bit frustrating for those of us whose big hope in life is to *replace* Windows, not to support it.
For Inkscape, popularity on Windows was sort of a side-effect not an objective. The entire raison d'etre of Inkscape (going back to the Sodipodi and Gill origins) was because of the lack of drawing tools on Linux. The proprietary Windows drawing app vendors refused to support Linux, so we all set off to fix that issue ourselves, and in so doing help make Linux a more viable alternative to Windows. For me personally, solving bug 1 is a big motivation to working on Inkscape.
In fact, while there had been some work on Sodipodi to do a Windows port, when we started Inkscape we dropped that, so we could focus on the Linux core. But it was not long before people who loved Inkscape and wanted it to work on Windows volunteered to undertake the porting work. We figured, hey, if it didn't impact the Inkscape core, and if these Windows contributors took care of all the porting work, what could it hurt to have more platform independence? These porters deserve a lot of credit - not only did they pull off a decent port, but the Windows version of Inkscape has proven to be extremely popular, and today our estimates are that we have vastly more Windows-based users than any other platform.
One could also argue that a Windows port could help provide a "stepping stone" for people to ease their migration from Windows to Linux. I have no clue whether this has come to be, nor know of any way to measure the significance of it if it has.
A point I often hear made is that having a good Windows port of Inkscape will "increase it's popularity." Perhaps, however popularity by itself isn't valuable - it needs to be translated into something tangible. For proprietary software, increased userbase means increased income, which allows hiring more developers to fix the bugs that the increased number of users are reporting. For free software projects, popularity doesn't bring value quite so directly - although you definitely get the increased number of bug reports!
In theory, you would expect that increasing userbase would result in increased number of contributers. This is the whole concept of Open Source - more eyeballs makes bugs shallow, a rising tide raises all boats, et al. I say 'contributor' rather than 'developer' deliberately, since value to an open source project can come in the form of a lot more than just code - documentation, translations, bug triaging, testing, marketing, tech support, and on and on.
So rather than just looking at userbase size by itself, consider the *ratio* of contributors to userbase. A platform with a high C/U ratio is going to have a lot more luck at stabilizing and optimizing its package than one with a low C/U. Commercial software can get by with low C/U's by paying developers to work on it; volunteer-only FOSS projects don't have that option though.
Thinking in terms of this ratio lets you think of larger problems in a bit different light. For instance, to determine if it's worth supporting a given platform, you could imagine comparing the C/U ratio to a Bugs/Userbase ratio. If C/U is too low in relation to the B/U ratio, the project won't be able to keep up with bug reports, so supporting the platform is going to literally be more trouble than worth.
This also lets you consider whether userbase growth due to increased popularity is going to be a good thing or a bad thing. If you have had a high C/U ratio previously, you can be relatively certain that increasing the userbase will bring with it a lot of new contributors. Often this can take the form of users simply helping each other out with answering questions on forums, helping with bugs, sharing tips and tricks, etc. This all represents value coming into the project, and is a strong sign of success.
On the other hand, with a low C/U ratio, increasing popularity may simply bring with it piles of bug reports and frustration by all involved. With few new volunteers coming in, existing ones risk becoming burned out, and the C/U ratio continues to decrease.
I also have a hypothesis that the base C/U ratio is platform-specific and derived from the level of technical knowledge and culture of that platform. In other words, by default, a Linux userbase will have a higher C/U than a Windows userbase, because the coder/non-coder ratio is higher, and because of cultural differences: Windows users are more accustomed to business models where they are simply consumers of products and their role ends at the point they submit a bug report; volunteer-involvement in a company's software product is not only a foreign concept but indeed something that can get you sued! On open source platforms like Linux, it's a completely different story - users are welcomed to be part of the collaborative process.
Another obvious question is, how do you improve your C/U ratio while allowing U to increase? A lot of ideas seem obvious - making the project more welcoming, encouraging people to get involved, providing ample training material, demonstrating how new participants can scratch their itches, encouraging them to learn coding, etc. Even though these ideas are so obvious, it's amazing that projects run into trouble fairly regularly because they've not done them - which can result in people not in the "inner circle" to not get involved; keeping C fixed while U goes up is just a recipe for disaster.
But I'm particularly curious how to deal with the situation of C/U on Windows. On the one hand, I don't particularly care to make life on Windows easier - I want people to switch to Ubuntu! But on the other, I want other people to take care of the Windows bugs; the existing Windows Inkscape supporters are obviously pretty overwhelmed, so really this means we need to get more Windows contributors. Telling Windows bug reporters the equivalent of "send a patch" gains either blank stares or outrage. Others would like to, but don't have the time or interest.
Sometimes, one way to increase contributions is to simply put the software bugs and all - in keeping with the "Release Early, Release Often" adage. This exposes the bugs to more people, at least some of which will be sufficiently bothered to put in the effort to fix it. But this is a mean thing to do deliberately to users.
Some would like to offer bounties, but honestly the amount of money required to compensate a developer for the time they spend fixing a bug is usually way beyond what a user can reasonably afford (and who wants to do the paperwork?) Personally I like the idea of bounty systems, but for whatever reason they don't seem to work in practice.
It's sort of ironic, that many of us got involved in Inkscape to further the aims of Open Source with the intent of getting people AWAY from Windows, yet since there aren't enough Windows contributors to cover all the problems particular to that platform, here we are with an expectation that we spend extra time supporting it. Do Not Want!
@Gatonegro
I've talked to a few folks since writing this article who had done the Windows->Linux switch and they made a couple interesting points.
First, like you point out, the existence of Inkscape as a cross-platform tool enabled them to switch to open source in stages. For them, drawing was a principle use of the computer, and so they needed to use Illustrator or other Windows-only tools; Inkscape on Windows enabled them to start migrating over slowly. Then, once they were comfortable with Inkscape as their primary tool, they then took the plunge over to Linux.
Second, most of the people who work on the Windows port (including Ishmal!) said they are actually Linux users day to day. So this is evidence that Windows is drawing labor that otherwise might be going to Linux. On the plus side, they didn't seem to mind doing cross platform support work.
So it sounds like, if our community is investing Linux-based resources into supporting a Windows port for the potential benefit of gaining Linux converts, we ought to step up our marketing to the Inkscape Windows users about why they should convert over.
It also says that while we shouldn't ship a "crippled" Inkscape on Windows, it may not be necessary to port 100% of our functionality over, where that functionality would require an excessive amount of platform-specific work. (Unless of course someone passionate about the platform really wanted to do it.) A good goal to shoot for would be to give Windows users a pleasant taste of what Inkscape can do, and some encouragement to switch to Linux so they can gain the full deal.