Delivering Solutions Using Open Source Software A Practical Guide For Program / Project / Product Managers And anyone else involved in delivering geospatial software solutions By: Scott Clark Program Manager PMP, PMI-ACP, GISP 

About me ● Project and Program Manager since 2007 ● Currently at Radiant Solutions ● I’ve led projects ranging from ○ R&D to transition to Operations ○ Shrink-wrapped products to specialized solutions ○ OSS and proprietary code bases ○ Restricted to Completely open ● All of my projects have involved software development ● These are all my own opinions and experiences ○ Hopefully they are helpful to you ○ (Your mileage may vary) ● I learn new things with every project 

I’m not a developer but… I’ve had the privilege of working with some great OSS projects Pelias 

Industry Practices Still Apply Approaches to running projects and building products or solutions are pretty well understood ● Agile Development ● Project Management ● Product Management ● Stakeholder Management ● User Engagement Regardless of the effort, these remain the foundation of how to deliver solutions 

Benefits of OSS to Delivering Solutions From an integrator’s point of view: ● No black boxes ● Linus’ Law ○ "Given enough eyeballs, all bugs are shallow" - Cathedral and the Bazaar ● Devs can delve into the code and troubleshoot ○ Make a pull request ● It’s not just for devs anymore ○ If the documentation isn’t great, anyone can pitch in ● Benefit from others’ investments ● You can roll up your sleeves and pitch in if needed ● Heavy reliance on open standards ● Reduces supplier risk 

It may be different from what you’re used to ● Community approach to code ● Public and open conversations ● Distributed contributors (organizationally & geographically) ● Multiple influences / influencers 

Benefits of a Community Access to a diverse community ● Diverse communities make great projects ○ Many perspectives ○ Wide breadth of experience ○ The larger the community the better this scales ● Look at what challenges they’ve dealt with ● Your “unique” concerns may not be that different from others 

Engaging with the Community You need to ENGAGE to reap the full benefits ● Understand how your goals fit into the community project roadmap ○ Core ○ Plugin ○ Community module ● Core committers ○ Your own team or a company ● Pull requests ○ Don’t just get accepted, talk to people ● Find developers comfortable with working with a community 

We get by with a little help from our friends “Open Source” does not = “Unsupported” Advantages of commercially supported / community supported OSS Look for ● Experience working with a particular codebase / community ● Ability to push fixes or features into core ○ Reduces maintenance costs ○ Avoids massive forking headaches ○ Ensures a more robust solution 

If you liked it, you shoulda put an Org on it Software supply chain assurance is a real concern in an enterprise ● Challenges with random open repos ○ How well reviewed is the provenance of the code we’re bringing in? ○ If it’s a one-person show, external pull requests may or may not be tightly reviewed ● Health of a project ○ Look at the commit history ○ Look at the mailing lists ○ What is the activity level of the project? ○ Is it still actively supported? ● And of course incubating through a foundation is helpful ○ LocationTech, OSGeo, Apache, etc. 

So, you want to start an OSS project… Or become active in a community Producing Open Source Software - Karl Fogel https://producingoss.com/ ● Organize your team to support it ● Be realistic about expectations 

Strategies with your Customer Be ready to address various concerns ● Contributing to existing OSS projects ● Open sourcing new code as a goal ● Understand OSS licenses ● Security and quality ● Intellectual Property ● Export controls and ITAR There are web sites from UNESCO, European Commission, World Bank GFDRR on the use of open source 

Working with Government Talking to government PMs ● US DoD OSS guidance ○ http://dodcio.defense.gov/Open-Source-Software-FAQ/ ● It’s Commercial off the shelf software (COTS) ! ● Considerations ● How to work in the open ■ NGA: GeoWave, MAGE, DICE, etc. ■ 18F ● If the government (taxpayers) pays for it, ideally it’s available to the public ○ With few valid exceptions 

Measuring ROI of OSS for an Organization ● GeoNode case study - World Bank GFDRR ○ Open Data for Resilience Initiative & GeoNode: A Case Study on Institutional Investments in Open Source https://opendri.org/resource/opendri-geonode-a-case-study-for -institutional-investments-in-open-source/ ● Leveraging Open Source as a Public Institution ○ Vivien Deparday, Robert Soden https://blogs.worldbank.org/opendata/leveraging-open-source- public-institution-new-analysis-reveals-significant-returns-inve stment-open 

In the end it’s really about workflows In our projects, we primarily measure ROI in terms of productivity and workflows but also point to advantages in scaling ● OSS is awesome but Can I do my job? ○ Faster? ○ Better? ○ More effectively? ○ Cheaper? ● Costs related to scaling? ● Training considerations? ● Find a customer champion that understands how to quantify these things