[Freegis-list] GASB-34 compliance with open source software (fwd)

[Jack Varga]

---------- Forwarded message ----------
Date: Fri, 6 Jun 2003 14:27:23 -0600 (MDT)
From: Jack Varga <jvarga at boulder.net>
To: Paul Ramsey <pramsey at refractions.net>
Subject: Re: [Freegis-list] GASB-34 compliance with open source software

Paul, 

Great stuff, and thanks.  First, a couple clarifications.  The concept 
includes two levels of stakeholders, the community at large that would 
benefit from the implementation, and the department whose current 
responsibilities include overseeing asset management.  In this particular 
model, the latter group, (I'll call them the department), would oversee the 
development of requirements for the system.  They would go through a 
couple/few iterations and then make the the requirements available for 
public comment, but ultimately the department would be responsible for 
the system, after all they have been apointed stewards for maintaining 
the specific assets.

In essence you're correct in that developing a set of requirements 
costs money, but that simply can't be avoided.  As a matter of fact, 
requirement (IMO) should always be driven seperate from some preconceived 
notion of a solution.  Said another way, they should be driven by the need 
to complete some business process.  a set of business processes.

The second clarification, in this model the presumption is that perhaps 
one or more open source applications could serve as the foundation for 
fulfilling the business process.  For that matter, so could some COTS 
application, or more realistically a combination of the two.  The work 
then is simply an integration effort.

If a particular community had an able enough developer base (Silicon 
Valley for example) that had a vested interest of their own in supporting 
the development (akin to building a community playground) perhaps a large 
portion of the development costs could be eliminated.

The reality is this kind of model is not possible with proprietary 
applications because the api's used for extending those applications 
can't be opened enough to allow your developer community access to the 
API.  

Consider for a moment a city with a large SDE implementation holding 
several data layers.  An open source application could be written using a 
tool like GRASS (or some other GIS) that extracted data from SDE using the
OGC's simple features specification and GML/XML to render map data.  Such 
a project would be relatively simple to implement with a good set of 
requirements.  

Hope this helps a bit.  

-j
 
On Fri, 6 Jun 2003, Paul Ramsey wrote:

> Hi Jack,
> 
> Community-based OSS development efforts have been an interest of mine 
> for a while, but sadly I have yet to see anything particularly compelling.
> 
> The sad truth is that for complicated systems (like your asset tracking 
> example) the initial design and development costs are pretty steep. 
> Using OSS building blocks can knock down the component costs of the 
> software, but the structure still needs to be built and documented 
> before ordinary mortals can implement it. The large up front costs for 
> things like an asset manager end up driving the software development 
> into a few standard channels.
> 
> The first, and most conventionally understood channel is the canonical 
> proprietary model -- a company assumes front-end cost and risk of 
> software development with the hope of recouping dollars through software 
> sales down the road. Overlaying an OSS licencing model onto this 
> scenario, the company only magnifies it's downstream risk (X% of users 
> could simply implement the software without paying the company a dime) 
> while not receiving alot of perceived benefit.
> 
> The second model is probably alot more common, sadly. A company sells a 
> (rich) client a partial solution (sometimes duplicitously implying it 
> already exists), and takes a moderate underfunded (but not unfunded) 
> risk developing the software from scratch. Multiple development 
> iterations (funded by the client still) ensue, until the product meets 
> their needs. At this point the company start re-selling to other 
> clients, using the initial client as a reference case.
> 
> The third model is like the second, but requires an enlightened client. 
> The enlightened client realizes that the second model is not 
> particularly to their benefit (why fund some company's R&D and get 
> nothing back but a maintenance bill?) and instead of "buying" this (as 
> yet unbuilt) "product" from the company, contracts for the software to 
> be built and open sourced. We are getting close to your goal now, but we 
> still require an initial client wealthy enough to fund 100% of the 
> development themselves, and enlightened enough to just "give it away" 
> when they are done. This has happened a few times, often by accident as 
> software for "internal use" was found to be of interest to a wider 
> community (GRASS springs to mind).
> 
> The fourth model I have never seen happen. This is where a number of 
> clients with the same requirements (like your asset management problem) 
> band together to contract for the required development and open source 
> it. The initial development cost is shared, and the resulting software 
> can be enhanced and improved (etc etc) in the usual OSS way. The fourth 
> model is just so far removed from the usual way people think about 
> software, and there is so much perceived risk around it, that it has not 
> really happened yet. It requires a fair amount of coordination and trust 
> amongst the partners, which are not attributes normally ascribed to 
> competing juridictions. And why go to all that effort (and take all that 
> risk) when there is a "COTS" solution the friendly neighborhood software 
> vendor is flogging? The initertia of the existing IT decision process 
> mitigates against option four pretty heavily.
> 
> What have your experiences been?
> 
> Yours,
> Paul
> 
> Jack Varga wrote:
> > Greetings, 
> > 
> > I'm investigating the feasibility of using OSS as a tool to be used for 
> > complying with the US-based Government Accounting Standards Board 
> > Statement'34 (GASB-34) on improved financial accountability for state and 
> > local governements.   Particularly to assist in the section that covers 
> > first time information about the government's public infrastructure 
> > assets, such as bridges, roads, storm sewers, parks and rec facilities, 
> > etc.
> > 
> > I'm curious if there are subscribers to this list familiar with GASB-34 
> > that have either implemented, or are considering implementing any open 
> > source GIS tools for asset tracking.  
> > 
> > Furthermore, I'm looking for precedence in managing true community-based 
> > development efforts to implement open source (in general) GIS/mapping
> > systems. Or to find out if there would be any interest in assisting with 
> > such an initiative, however moderate involvement may be.
> > 
> > Info on GASB-34 can be found at http://www.gasb.org/repmodel/index.html
> > 
> > All comments welcome.
> > 
> > Jack
> 
> 
>