Open/Community Source Applications: Learning to Play with the Other Kids CUMREC 2005 Barry Walsh Copyright Barry Walsh 2005. This work is the intellectual property of the author. Permission is granted for this material to be shared for non-commercial, educational purposes, provided that this copyright statement appears on the reproduced materials and notice is given that the copying is by permission of the author. To disseminate otherwise or to republish requires written permission from the author.

Some ‘Source ‘ Definitions Open Community 12/9/2018 CUMREC 2005: Keystone

Pure Commercial Software Communication between Stakeholders and Shareholders is in the form of large checks. Shareholders Goal to maximize profit Developer priority profit Stakeholders Expect indemnification allows for a good night’s sleep? Users feel they have the best product that money can buy Can calibrate end-user demands for change Commercial Developers Revenue and paycheck! stability of software Do not even know stakeholders = Most Powerful in Structure Attribution to Joseph Hardin at U Mich Attribution to Joseph Hardin at U Mich

Pure Open Source Software Open Source Developers Type 1: Passionate individual Type 2: Paid consultants Teams formed based on personal time and motivation or a commercial venture with a short-term agenda Effort level can ebb and flow Cool features and programming chops rule the day (and night) Stakeholders Love “free” stuff. Hate that there is no one to call - “if it breaks you get to keep both pieces” Hate that there is no one to sue Must self-indemnify by keeping lots of staff “in case” something goes wrong. Once open source is chosen, may find it hard to sleep at night. Virtually no communication at all between Stakeholders and Developers Attribution to Joseph Hardin at U Mich Attribution to Joseph Hardin at U Mich

Community Source Attribution to Joseph Hardin at U Mich Secondary Stakeholders Look to Core developers for reliability/performance The Core developers have a boss! Pay money to Core to get “indemnification”? Can contribute to the Core “in kind”? Can join the core with enough commitment Can pay Commercial Support for “extra indemnification”. Commercial Support Can contribute in several ways Can make money from secondary stakeholders Core Stakeholders May represent a significant pool of resources If they pooled resources, they would be instantly larger than many small commercial R&D operations. Tired of writing big checks, and begging for features Form coalition of the “committed” Must learn that this is harder than it looks - must gain company-like skills. Actually responsible for both the development and production of the software. Core Developers Work for the stakeholders so they want to make the Stakeholders happy: By, of and for HE! Open Source Developers Limited ways to play in this game Attribution to Joseph Hardin at U Mich 12/9/2018 CUMREC 2005: Keystone

Community Source Projects “Community source describes a model for the purposeful coordinating of work in a community. It is based on many of the principles of open source development efforts, but community source efforts rely more explicitly on defined roles, responsibilities, and funded commitments by community members than some open source development models.” …. from www.sakaiproject.org Attribution to Joseph Hardin at U Mich 12/9/2018 CUMREC 2005: Keystone

Three Critical Stages Ongoing Support Harmonious Execution Formation Scope Funding Governance 12/9/2018 CUMREC 2005: Keystone

Formation: Formation 12/9/2018 CUMREC 2005: Keystone

Formation: Choose Partners Judiciously Like-minded Institutions Shared vision Functionally Technically Ya gotta WANNA!! Synchronized institutional clocks Within reason Long term commitment: Beyond Project? Tolerance for ambiguity 12/9/2018 CUMREC 2005: Keystone

Formation: Participants’ Volunteer Modes Our focus today Institutional Institutional/Individual Individual 12/9/2018 CUMREC 2005: Keystone

Formation: Creating the resources Defined Contributions Cash or Tendered Resources Tendered to Board For Duration of Project Qualified Resources As Judged by Peers Functional Technical Grants 12/9/2018 CUMREC 2005: Keystone

Harmonious Execution Harmonious Execution 12/9/2018 CUMREC 2005: Keystone

Harmonious Execution: Personal Good behavior begets good behavior. If you seed the core development team with good, well behaved people... they attract good, well behaved people. The weaklings and bullies just don't fit in and don't hang around. Likewise, well-behaved commercial partners set high bar for future behavior of commercial partners. …Carl Jacobson 12/9/2018 CUMREC 2005: Keystone

Harmonious Execution: Personal/Team Dynamics CSFs: Park ego at door; pick up on way out! Most of the smart people on the project work somewhere else! Bring brain! High Emotional IQ…Good Thing!! Superstar developers do not always make the best players here; but…it is not always an issue Aretha Franklin…….R.E.S.P.E.C.T! For other’s qualities For other’s campus or personal cultures It’s a Team Sport! “Individuals” need not apply!! 12/9/2018 CUMREC 2005: Keystone

Harmonious Execution: Logistical Co-location is optimal but unlikely Don’t skimp on the F2F opportunities Always-on Video Virtual-Meeting Software Webex, Breeze, LiveMeeting, etc. Prototype sharing/demonstration Collaborative Software Sakai, JIRA, Confluence etc. Time Zones!!! Animal House!! 12/9/2018 CUMREC 2005: Keystone

Harmonious Execution: Overhead Remote sites Team makeup/leadership Work Allocation Time-Zones 12/9/2018 CUMREC 2005: Keystone

Harmonious Execution: Technical Usually Not Research Projects Sometimes span multiple years Standards Architectural Platform Development Version Control Repository Balance Agility and Execution 12/9/2018 CUMREC 2005: Keystone

Ongoing Support Ongoing Support Scope Funding 12/9/2018 Governance 12/9/2018 CUMREC 2005: Keystone

Ongoing Support: Funding Community Source Requires Defined, Tendered Resources Commercial partners  A good thing Long term sustenance? A "grant-funded project" is different from an "open source" project. 12/9/2018 CUMREC 2005: Keystone

Ongoing Support: Scope Scope Creep A grant is a contract and an agreement to accomplish something. If the grant money was received to "paint it red" and the community wants to "paint it white"... it will be red as long as the grant is driving the bus. When the community process kicks in, they can paint it white. …Carl Jacobson 12/9/2018 CUMREC 2005: Keystone

Ongoing Support: Scope--The Rules of the Game You May Pick Any Two Scope Time The Reality Triangle I Get the Other ☺ Resources 12/9/2018 CUMREC 2005: Keystone

Ongoing Support: Governance Strong community is more valuable that strong governance. Early stages: a little more hands-on? Later: Zen? "Inclusive" is better than "exclusive“ largest possible community; accept free-riders; welcome commercial partners; Open-open licensing encourages inclusion and therefore the largest possible community. …Carl Jacobson 12/9/2018 CUMREC 2005: Keystone

Ongoing Support: Governance Founding Investors: uPortal UDel, Princeton, Andrew W. Mellon, JA-SIG, etc. Sakai: U Mich, Stanford, MIT, Indiana, Andrew W. Mellon Kuali: UA, UH, CU, SJD, MSU, IU, NACUBO, Andrew W. Mellon FEDORA: UVa, CU, Andrew W. Mellon 12/9/2018 CUMREC 2005: Keystone

Governance Evolution Investment Partners Founding Partners Community Partners Investment Partners Founding Partners 12/9/2018 CUMREC 2005: Keystone

In the end, it’s all about the Community 12/9/2018 CUMREC 2005: Keystone

Questions/comments? 12/9/2018 CUMREC 2005: Keystone

12/9/2018 CUMREC 2005: Keystone

Abstract: Open and Community Source applications have begun to emerge as viable alternatives for some institutions. However, unlike infrastructure efforts such as Apache or Linux, community source applications involve players beyond the IT space. Joining these efforts and subsequently engaging in productive collaboration with other institutions present challenges for some institutions. The presenters will offer ideas on best practices in successful collaboration. 12/9/2018 CUMREC 2005: Keystone

Outline: Problem Statement: Engaging in collaborative efforts to develop software is not trivial. Three distinct stages require attention: formation, execution and ongoing support. 12/9/2018 CUMREC 2005: Keystone

Activity: Technology is not always the principal hurdle to be overcome. The interpersonal and inter-institutional issues can loom larger at times, but there are several excellent examples of successful collaborations. In some cases, the governance of the collaborative group was the key success factor. In others, individuals played key roles in assuring success. The presenters will explore some possible best practices that help assure successful outcomes, both initially and longer term. 12/9/2018 CUMREC 2005: Keystone

Relevance to other institutions: Any institution that is considering engaging in the actual development effort or in using the resulting software might benefit from a greater understanding of the issues surrounding the community source movement in higher education Audience: CIOs, executives, potential development/functional partners and projected users of community source software. Presenters: John F. Walsh (Lead)  Indiana University  Previous Presenter Information 12/9/2018 CUMREC 2005: Keystone

Good behavior begets good behavior Good behavior begets good behavior. If you seed the core development team with good, well behaved people... they attract good, well behaved people. The weaklings and bullys just don't fit in and don't hang around. Likewise, well-behaved commercial partners set high bar for future behavior of commercial partners. Strong community is more valuable that strong governance. A community process that allows the community to drive the bus is necessary, although the first years, or the "grant funded" years may require stronger governance. Its easier to "seed" or "cultivate" than "direct" or "manage". Zen management with some hands off. A "grant-funded project" is different from an "open source" project. A grant is a contract and an agreement to accomplish something. If the grant money was received to "paint it red" and the community wants to "paint it white"... it will be red as long as the grant is driving the bus. When the community process kicks in, they can paint it white. Commercial partners are a good thing... they can provide a sustaining future for collaborative projects. "Inclusive" is better than "exclusive"... allow largest possible community, accept free-riders, accept all commercial partners... collaboration can be limited to a naturally forming community... like "higher ed" or "education" or "higher ed researchers". Open-open licensing encourages inclusion and therefore the largest possible community. Collaborative software projects lower in the software stack easily attract volunteer developers, further up the stack where appeal is less technical and more functional, developers need to be paid and institutional volunteering is more likely than individual volunteering. 12/9/2018 CUMREC 2005: Keystone