beeware
A view from the other side - the commercial interests
First a plea - please don't misunderstand me. I believe in the fundamental issue here - once Open Source projects grew beyond the 1- and 2-person garage projects, it became inevitable that some form of sustainable cash flow would become a requirement. I'm not trying to disparage the need - just to provide a perspective on some issues that I don't otherwise see covered here. This perspective comes from working as a "corporate drone" for 35+ years in very traditional, fundamentally conservative business environments. My opinion, for what it's worth, is that any model will need to address these issues if it's going to be successful.
-
Open Source - for the most part - made its way into the corporate environment via the techies, able to sell it to management as a lower-cost solution to proprietary products.The lower cost wasn't just the price of the software itself, but also the ancillary expenses involved in accounting, license management, acquisition management, etc. Those overhead expenses are, on a corporate hourly basis, often significantly higher than the cost of a commodity product. Force a corporation to go through that, and you'll have people searching for alternatives again.
-
For just about every significant Open Source package, there's at least one viable alternative. Need to pay (or donate, or contribute) to use Linux, but don't want to? Fine, there's always the flavors of BSD available. As one of the other issue authors pointed out, it becomes a very real issue of "competitive advantage". A company intentionally incurring an expense avoided by others is placing themselves at a real disadvantage.
-
Licensing issues abound. As Linus has pointed out in the past, Linux itself is encumbered by the hundreds of different people who have all contributed code with the understanding that it would all collectively be distributed under GPL 2. It's a practical impossibility for Linux's license to be changed at this point. (I do recognize that there are projects that require contributors to sign over their rights to an organization or foundation - making it easier for them to change their license. But...)
-
Distribution issues are real. I don't know how true it is any more, but when I started using OSS, the packages I used generally were those distributed by the distros. I would occasionally build packages on an as-needed basis, but if I had to make a decision between a package supplied with the distro, and one that I had to build myself, I would need a compelling reason to go the DIY route. (And that's going back to my first installation of Yggdrasil more than 20 years ago.) From a corporate perspective, staying with a managed source is considered "safer" that "side-loaded" builds. My point here is that any funding model needs to be sensitive to the common distros, and their ability to package and distribute this software.
-
Education and influence. Most of the techies I know in the corporate world actually are sympathetic to this need. But the techies don't control the budget or the funds. We (and I very much include myself here) need to do a better job of making the business case that this software has significant strategic value to the corporation and needs to be supported - even voluntarily. The problem is, that if project "X" goes dormant, the software built on "X" will still run - generally for long enough for an alternative to be found. That means that there's little urgency or incentive to be pro-active concerning project support. (Software in corporations does tend to stick around for a long time. I know a place that still has 3 servers running that were built in 1998 with 64MB RAM and an 8 GB hard drive, that are still running today as file and print servers.)
Solutions to these? Unfortunately, I have none - but then I haven't lived this problem like many of you here to have really thought about it.
I agree in principle with the issue author who said that the developers need to make contractual arrangements - but not for 20% time or anything else like that. Either the corporate developers need to require their companies to support the projects, or else require salaries that allow them to make the appropriate contributions. Again though, the problem becomes one of competitive advantages of those who participate vs those who don't.
Playing up the role of being a good "Corporate Citizen" may also be a part of this. Advertising - make it prominent in the projects themselves who is supporting you. (You could go the "Nagware" route. Build "watermarks" or other identifying information into your official build. Nothing truly obnoxious or disruptive - but visible somewhere. Charge for an official build of an unmarked version. Sure, people would still have the ability to clean it up themselves, but most won't want to bother doing that for every release / update.)
What I don't see of value are the suggestions along the lines of selling support contracts, training, or other ancillary services. If your core objective is making "X" better, any time you spend doing anything other than working on "X" is a net loss. All you've done is changed the business you're in to those other services, and you're back to working on your original project as a hobbyist effort.
Finally, any real movement in this direction needs to be significantly larger than just a handful of projects. The solution - if it's going to be truly effective - needs to have very broad support from the OSS communities. And at that point, it might become necessary or desirable to create an umbrella organization like an ASCAP that would be capable of supporting an effort like this.
This is antithetical to the OSS model. And even if it were palatable to the community, most of the OSS I am interested in are not front-end visible in the way where you even could watermark. Think things like templating languages, form building libraries, autocomplete mechanisms, database connections, ORM filter mechanisms, message queue abstractions.
