1. Open/Community Source Applications:
Learning to Play with the Other Kids
CUMREC 2005
Barry Walsh
Copyright Barry Walsh 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.

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

3. 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

4. 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

5. 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

6. 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
Attribution to Joseph Hardin at U Mich
12/9/2018
CUMREC 2005: Keystone

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

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

9. 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

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

11. 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

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

13. 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

14. 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

15. 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

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

17. 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

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

19. 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

20. 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

21. 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

22. 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

23. 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

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

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

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

27. 12/9/2018
CUMREC 2005: Keystone

28. 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

29. 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

30. 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

31. 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

32. 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