<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">There might be some insights if we draw parallels between these open source funding issues and how traditional closed-source companies finance what they do.<br><br>Actually the differences between open and closed source may be more instructive: It seems to me that open source is, essentially, not-for-profit by nature. Putting aside any incorporation legalisms in our respective countries as to what defines not-for-profit, the fact that open source precludes the write-once-sell-many, per-seat or -site license model means there is no realistic opportunity for a non-linear return-on-investment. So we can forget about funding sources such as venture capital, large-volume private investors, business loans, publicly traded stock -- or getting bought by Microsoft :)<br><br>Put another way, open source is a services model. There are plenty of
for-profit software service providers out there; they tend to categorize their efforts as billable vs non-billable. The administrative work, such as documentation, QA, release management -- plus the overall task of keeping the OSGeo infrastructure umbrella healthy -- fall under non-billable. The for-profit business handles this by charging enough for billable work to cover the non-billable expenses. What is the open-source equivalent of this? Individual projects paying 'dues'? Mostly it is the massive amount of volunteer work within the projects or within OSGeo committees.<br><br>If a commercial software services company's business model is based on customizing a popular off-the-shelf product, then they can really let ESRI or Autodesk or Bentley or Intergraph of whoever worry about how to finance development of the core product. <br><br>In my own independent consulting, my relationship to Mapserver, PostGIS, and so
forth has been to set up these free products for a client and build a custom solution around them -- and charge for the entire exercise. I can imagine enhancing a core product and passing on that expense to client, providing I make it clear up front that a portion of what's being developed will enter the public domain. But only if the cost of the improving the core is relatively small and is a critical component of the total solution. Otherwise, my client is likely to complain "Hey, why am I paying for all this stuff that everyone else is going to be able to use for free?"<br><br>This leaves the open source projects somewhat at a loss for a predictable way of adequately funding the write-once-give-away-many core product, given that most of the established means used by the closed-source entities to fund their per-seat/per-site systems aren't applicable.<br><br>I'm very interested in exploring what kind of formal structures the open
source developers AND users can construct whose advantages most closely match -- in the eyes of the users -- the advantages of the traditional off-the-shelf license-based product model they've been conditioned to expect and utilize for decades. Primarily: pay a predictable, "reasonable" sum of money to acquire a quantifiable set of application capabilities, where the total development cost of those capabilities far exceeds the price they are paying.<br><br>Meanwhile, these structures must retain all the well known advantages of open over closed source. Moreover, this model must accommodate large volumes of core product development, and, at the same time, integrate well with per-client customization services.<br><br>Robert H.<br><br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><br><div id="yiv743498621"><div>
<div><span><div><span>So the danger with any kind of "bounty" funding model is it misses out on:</span></div><div><span>- paying osgeo to keep the servers up and the lights on</span></div><div><span>- documentation</span></div><div><span>- quality assurance</span></div><div>- other "maintenance" activities website, release of software, check issues to produce release notes etc...</div><div><br></div><div>Now I know none of the above is as sexy as asking people to fund a specific feature they are interested in. In a couple of projects I work on; I will pick on GeoTools as an example, we are well served by the existing model where developers work; often as consultants; to add specific functionality to the library. But it has not always been so smooth and we had to adjust our procedures to avoid trouble.</div><div><br></div><div><div>As an example just today I had a user on IRC asking how SQLViews work. This functionality was added, on contract,
to meet a deadline - and has not been documented. </div><div><br></div></div></span></div><div><span></span><span>The challenge is to patch up the funding model does so it captures enough resources to do everything that is required. </span></div><div>- In GeoTools we have taken steps to make the tasks actually required visible. The developers guide offers volunteers, contractors and other potential investors specific QA and documentation targets to be met for the functionality to be included. It also offers a "jail" of unsupported modules where code lives that has not yet met the requirements; the steering committee does not distribute this code; but it is there for people to work on as they have time.</div><div>- We also have adjusted our change control procedure to list a number of tasks to be performed; with *names* next to them. This allows to check that "the next great idea" has enough volunteers available to proceed in a safe fashion.
This is often where volunteers providing help testing can make a massive difference.</div><div><br></div><div>So when gathering up resources for a "feature" consider putting down a series of price points with a clear indication of what can be accomplished at each price point. You can even include OSGeo as one of the earlier price points (perhaps next to a subversion branch) and some of the later ones (white paper and publicity).</div><div><span>-- <br></span><br><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><div><div class="plainMail"><blockquote><blockquote><blockquote type="cite"><div>Robert Hollingsworth <<a rel="nofollow" ymailto="mailto:reh2@prodigy.net" target="_blank" href="/mc/compose?to=reh2@prodigy.net">reh2@prodigy.net</a>> 06/04/11 9:32 AM >>><br></div></blockquote></blockquote></blockquote>I've been discussing variations on an idea for a while with
various people:<br><br>Form pools of users <a href="http://lists.osgeo.org/mailman/listinfo/discuss" target="_blank"></a>...<br></div></div></span></blockquote></div></div></div></blockquote></td></tr></table>