Benjamin Otte’s Open Source will scale brings up an interesting point.
If currently 1% of the world uses GNOME and it suddenly were 100x as many, we’d be at 40 million bugs right now.
The persistent lie that increased usage guarantees hordes of available volunteers descending from heaven to wipe out all signs of resistence (accompanied by the appropriate Wagnerian soundtrack) is one of the most pernicious Myths Open Source Developers Tell Ourselves.
Though Benjamin finds hope in the fact that users tend not to report bugs (and distributions don’t work well enough with upstream), the entire scenario still bothers me. I don’t mind fixing an interesting segfault now and then, and I’m always happy to fix a well-reported bug with a test case and a sensible description which helps me reproduce the problem. Yet I don’t scale, especially for projects where I can devote only a few hours a week.
That’s not a few hours every week, either.
Bug reporting, bug triaging, and bug fixing are all activities present in healthy project communities. In return for the freedom of using great software (often at low or no cost) with no usage restrictions and few (if any) distribution restrictions, users have the responsibility of ensuring the community’s long-term health. That may mean submitting a bug report, testing a development version, posting a bug bounty, producing a patch, or even sponsoring a developer. Otherwise, you’re relying on the goodwill of volunteers who’ve already more than paid their obligations to you — and I’m concerned about the long-term sustainability of that model.
Sometimes I wonder of the dual-licensing model is actually healthier in some ways. At least there the costs are explicit and fungible.
I assume your implied leeches are mainly corporate developers and various dilettantes coming from weird backgrounds. In my experience, corporate users who submit any type of bug report do so rather immaculately; it's true that bug reports come out of corporations less frequently than they do from the Standard Cabal, but when they do it's usually because some developer cares enough to overcome any resistance put up by their organization to communicating about their code with the outside world, so they're that much more motivated to make it count and get the problem solved, so I'm usually well inclined to want to help them.
Whether I have enough time is another matter, of course. But at least they're holding up their side on the front end.
I also think there's a meaningful difference coming from the kinds of applications that must be built in different settings. In my corporate day job, the desired features come first, then we spec it out and figure out what ingredients, whether OSS or proprietary, will be necessary to build it. Often there are dozens of packages that go into any given solution, and we don't have the luxury to get very familiar with any one of them, so we're not often in a good position to even make very helpful bug reports.
Contrast that with my evening "job", where I do OSS pet projects, and I have intimate knowledge of the small handful of closely-related packages I depend on. My contributions to those projects are much more likely to be relevant and useful.
I agree that it's good to educate any user about the ideal relationship between them and the OSS contributor; but be aware that often those users are going out on a limb to use your stuff in the first place. If they had to jump through additional licensing hoops too (which I think is what you meant by the "dual-licensing model" comment?) many users just wouldn't bother, they'd roll their own solution or turn to other proprietary stuff, and I think ultimately that's not so healthy either.