community source studying the relationships between developers shareholders and stakeholders n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Community Source Studying the relationships between Developers, Shareholders, and Stakeholders PowerPoint Presentation
Download Presentation
Community Source Studying the relationships between Developers, Shareholders, and Stakeholders

Loading in 2 Seconds...

play fullscreen
1 / 10

Community Source Studying the relationships between Developers, Shareholders, and Stakeholders - PowerPoint PPT Presentation


  • 151 Views
  • Uploaded on

Community Source Studying the relationships between Developers, Shareholders, and Stakeholders. Charles Severance University of Michigan Sakai Chief Architect 10-15-2004.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Community Source Studying the relationships between Developers, Shareholders, and Stakeholders' - edita


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
community source studying the relationships between developers shareholders and stakeholders

Community SourceStudying the relationships between Developers, Shareholders, and Stakeholders

Charles Severance

University of Michigan

Sakai Chief Architect

10-15-2004

slide2

“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

models
Models
  • Commercial
    • Pure: PeopleSoft
    • Commercial GPL/LGPL: MySql or RedHat
    • Support of Open Source: Many small companies
  • Open Source
    • Open-Open: Jakarta Httpd / Tomcat
    • Academic GPL: emacs
  • Community Source
    • Community Open-Open: Sakai
actors
Actors
  • End-Users
    • Students, faculty, staff,employees, etc - just trying to hand in their homework and other mundane tasks
  • IT Stakeholders
    • Customers of the software - often IT organizations who purchase and deploy software on behalf of end users. Jobs usually depend on the happiness of end users and upper management.
  • Developers
    • The people who produce the software.
  • Shareholders
    • The people who profit from the software
pure commercial software
Pure Commercial Software

Communication between Stakeholders and Shareholders is in the form of large checks.

  • ShareHolders
  • Desire to maximize profit
  • Make most decisions so as to maximize profit
  • Have final say in terms of developer priority - usually priorities have to do with profit
  • StakeHolders
  • Expect that because so much money is being paid that there is some form of indemnification in return (no one was ever fired for buying Cisco)
  • Are willing to pay handsomely so as to be able to get good nights sleep
  • Tell end users that they are using the best product that money can buy
  • Can resist end-user demands for change because company is unwilling to change
  • Commercial Developers
  • Understand critical link between revenue and paycheck
  • Focus is on stability of software rather than on features - as such features change slowly
  • Do not even know stakeholders

There is almost no direct communication between stakeholders and developers because then the developers might actually start changing (and breaking) the software.

= Most Powerful in Structure

pure open source software
Pure Open Source Software
  • Open Source Developers
  • Type 1: Passionate individual who finds work on this software interesting
  • Type 2: Paid consultant whose job it is to get a open-source software to pass test suites so as to show that there is an open-source reference implementation
  • Teams formed based on personal time and motivation or a commercial venture with a short-term agenda
  • Effort level ebbs and flows depending on commercial needs of the moment
  • Performance and reliability are second-order issues
  • Cool features and programming chops rule the day (and night)
  • StakeHolders
  • Love the notion that they have free software and source code.
  • Hate the fact that there is no one to call - “if it breaks you get to keep both pieces”
  • Look at open source solutions at a moment in time and make a yes/no decision based on state of the software at the moment of analysis
  • Must self-indemnify by keeping lots of staff with questionable grooming habits “in case” something goes wrong.
  • Once open source is chosen, may find it hard to sleep at night.
  • Probably won’t get to keep the savings form the open source decision beyond this fiscal year.

There is virtually no communication at all between StakeHolders and Developers because they operate in completely orthogonal areas of the space-time continuum and if they ever ran across one another - they would not even recognize that they were in the same species.

commercial in the middle small
Commercial In The Middle (Small)
  • StakeHolders
  • Have someone to call
  • Tell their management and users that we have indemnification
  • Since this is commercial and it is paid for, it must be good (aka Ostrich)
  • Secretly know that the indemnification only goes so far
  • Works best when stakeholder does not think too much about their situation.
  • Pretty safe for smaller organizations because no one is ever really fired for bad decisions
  • Commercial Support Houses
  • Money for nothing is a nice Business Model
  • Keep a small stock of talented folks fed
  • Most of the time you are totally bored playing multi-player games
  • Some of the time, you jump on a plane and put out a fire at a customer site
  • Once in a great while you get sued, go out of business, wait a few weeks and start a new business
  • Open Source Developers
  • Nothing really changes
  • If a developer from commercial support house has chops, we let them fix a few bugs and pat them on the back.
  • Performance and reliability take a back seat to fun stuff
commercial in the middle large
Commercial In The Middle (Large)
  • Commercial Support Houses
  • We write this software
  • It is fast and reliable
  • We are professional developers who will be around for a while
  • We have decided that publishing source is good marketing
  • We have decided that giving software away to cheapskates is better than having them steal the software or use something else.
  • Start them off free, move them toward the pay stuff
  • If they don’t pay enough voluntarily, use F.U.D. to increase revenue.
  • StakeHolders
  • Really have someone to call
  • Indemnification is real and has a very clear price
  • A decision can be made based on the value of a good night’s sleep.
  • If the company engages in constant F.U.D. operations you bite the bullet, pay the ransom, grit your teeth and hope for something better to appear someday.
  • If the company uses F.U.D. sparingly and keeps prices reasonable - this can be very stable.
  • Open Source Developers
  • Not really the main event
  • Thanks for the bug fixes guys

This configuration usually lasts less than 10 years in the honeymoon state. At about 10 years, the number of Vice Presidents exceed the number of actual workers. To keep up the Lamborgini payments prices must rise, but then stakeholders switch to the free versions, so the company upps its F.U.D. campaign intensity. This either tends toward pure commercial or has a blow-out.

community source
Community Source
  • Secondary StakeHolders
  • At least the core developers have to be responsible for reliability and performance
  • The core developers have a boss who can be complained to
  • Can pay some 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
  • At least the core developers have to be responsible for reliability and performance
  • The core developers have a boss who can be complained to
  • Can pay some money to the Core for some “indemnification”
  • Can make money from secondary stakeholders
  • Core StakeHolders
  • It turns out that they actually have a lot of money and programmers
  • If they pool resources, we 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”
  • Get quite excited when developers start doing what they are told.
  • 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
  • Open Source Developers
  • Can participate in the process based on contributions and chops

Issues:

How can this be kept stable after founders reduce commitment?

If successful, what stops this from going commercial?

What is the right license for the IP produced as part of the Core?

What types of software is appropriate for this? Payroll software?

sakai and community source
Sakai and Community Source
  • Sakai is defining Community Source
    • Commitment to collaboratively build, deploy and share a single collaborative learning solution across 4(6) campuses Fall 2005.
    • Clever choice of application
      • Commercial competitors are not giving strong value versus price
      • Learning and research collaboration is part of the University core mission - makes it logical to develop in house.
    • Diverse management and technical talents on the team makes the team stronger (discussions are lively at times)
  • This is not as easy as it looks but so far the benefits outweigh the costs.
  • It is like a marriage - you have to keep working on the relationships all the time.
  • When it works, it is a beautiful thing