Open Source Tools and Proprietary Software Who we are Why are we developing software and using Open Source Tools What we are doing How we are implementing the tools When is this happening What is next

-Who we are- (ORMAP ESRI User Group) ORMAP – Department of Revenue administered project to help fund and build a digital taxlot map for Oregon. – ESRI User Group – A subgroup of ORMAP counties that use ESRI Technology and work together. –ORMAP->Cartography>Parcel Data Model

-Who we are- (ORMAP ESRI Tools Group) Tools Committee – A subset of the ORMAP ESRI User Group that have technical resources available to build tools (Use ArcMap 9.2, VB, & VBA) Members – Department of Revenue and counties including Clackamas, Clatsop, Deschutes, Jackson, Lane, Marion, and Polk.

-Why are we doing this- (ORMAP ESRI Tools Group) Software –All converting from Arc/Info to ArcMap –All need software customized Business Process –Similar organizational structures –All need to make maps that meet state specs –All have similar map maintenance procedures –All have limited funding Users –Cartographers maintain and produce maps

-Why are we doing this- (Open Source) Technical Resources –Distributed programmers with limited time –Can not afford ESRI or contractors –Want to avoid being locked to one developer –Want innovation & faster development –Want the community to evolve and grow Software –ESRI software needs a lot of customization –Same/similar software problems –Want maintainable software Willing to bear disadvantages

-What are we doing- (Developed a data structure) Created a consistent database structure for all ESRI ORMAP Users –3 Rd version is complete and tested –Got help from ESRI (Jeff B.) –Hired Nancy Tosta Shared methods to convert data –AML and ESRI MODELS –Got help from ESRI Help (Jeff B.)

-What are we doing- (Developed Prototype Software) Designed and had a prototype built –Identified & documented requirements –Got help from ESRI (Jeff B.) –Provided lots of input to ESRI (CoGo) –Hired ESRI to develop a prototype

-What are we doing- (Developing Production Software) Developed an Open Source process for sharing resources and developed Release1.1 of the software for ArcMap 9.2 with CoGo –Editor Tools – Clackamas & Polk (VB &VBA) –18x20 Map Tool – DOR and Lane (VBA) –18x24 Map Tool – Clatsop and Marion (VBA) –SW Administration – Clackamas –Group Coordination – Polk

-How are we doing this- (Decided we were desperate) Decided we were desperate enough to risk a joint development process Counties & DOR volunteered staff Developed an organizational structure (central support model) to make it happen –Administration, Programmers, Users ….. Started To Cooperate

-How are we doing this- (Developed Coding Standards) –Match what has already exists in the tools code from ESRI –No data type suffixes $, %) –No my… –Add header see add-in from James, ask him to modify it to be a bit shorter –Releases of source forge have line numbers only when they are in the trunk (master copy) –Delete any code that is no longer needed. –Prefixes: s = string, b = Boolean, i = integer, m = module, g = global –Use the following abbreviations: MI MapIndex, TL Taxlot, FC Feature Class, Def Default Values, C Cartographic lines –Use p for Pointer –Add comment to the top where your work has been added… –Set variables to nothing at the end of the functions. –Consistent indentation

-How are we doing this- (Developed a process) 1. County user requests a change (enhancement or bug fix) using sourceFORGE (County programmers or any county in the ORMAP group can partner with a tools committee member to discuss and take on a tool request) 2. Tools committee member volunteers to code and fills out a Tool Design Document and presents it to the Tools Committee 3. Tools Committee approves project & another county volunteers to test 4. County performs work and places code into the countys branch in Source Forge

-How are we doing this- (Developed a process) 5. Testing county reviews work (both user environment and programming) 6. County presents the tool to committee who excepts/rejects tool for the next general release so county can get paid by ORMAP (if funded) 7. sourceFORGE administrator merges code for next general release 8. Counties test next release 9. Present new tools to the ORMAP user group 10. Next release is published

-How are we doing this- (Developed Specification Sheet) OVERVIEW –Tool Name (short 10 word description ie: adding annotation hooks) –Justification (why do it): –Brief Deliverable Overview (proposed solution): REQUIREMENTS (Complete before review) –Current Process Summary (how does it work now): –Desired Process Summary (how should it work): –Assumptions/Constraints: DESIGN (Complete before review) –Start & End State: –Inputs & Outputs: –Process: –User Interface:

-How a request is made- SourceFORGE Request *Any user can make any type of request.

-How a request is made- Requests *Any tools committee county can take on a project. The project has to be approved to ensure that the results will meet DOR specs.

- How code is managed- Tortoise Subversion Use Subversions update function to get software

-How code is managed- Subversion Commit Commited to SourceFORGE (Conflict resolution & merge)

- How code is download- Anyone can download compiled software and source code.

-How To Summary- RELEASE User Community REQUESTS SPECS Developer CODE Developer SourceFORGE s/Word Subversion Developer Committee

-How are we doing this- (Issues) Need a SW Administrator & Web Host Clackamas County & Department of Revenue Need Volunteer Developers Clackamas, Clatsop, Lane, Marion, Polk, DOR Funding Counties can spend any amount of money on coding but ORMAP funds are limited. Need user documentation & helps Software is not licensed or restricted

-When is this available – (Version 1.1) Editor 1.1 is done and available 18x20 Plot Production is in testing. 18x25 Plot Production is in testing. Working on helps & documentation. The release meeting is scheduled for…. …. May 15, 2007

-What is next – (Version 2) This spring/summer –Possibly develop additional tools –Possibly port the software to VB.Net –Make tools independent of the data model.

Conclusions The process works for our limited user base (ie: needs our database design to work) We have implemented a pragmatic Central Support Model with sharing and evolution of code (opposed to other open source development models) We have no restrictions on the code