• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
OSS2009 Øyvind Hauge
 

OSS2009 Øyvind Hauge

on

  • 401 views

Presentation of the paper "Providing Commercial Open Source Software: Lessons Learned" from the OSS2009 conference in Skövde, Sweden

Presentation of the paper "Providing Commercial Open Source Software: Lessons Learned" from the OSS2009 conference in Skövde, Sweden

Statistics

Views

Total Views
401
Views on SlideShare
400
Embed Views
1

Actions

Likes
0
Downloads
0
Comments
0

1 Embed 1

http://www.linkedin.com 1

Accessibility

Upload Details

Uploaded via as OpenOffice

Usage Rights

CC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • There are several possible reasons why a company would want to release an OSS product. In large companies this release is often related to other services/products for which they make profits, and just a small part of the company's business. For SME releasing an OSS product may concern their whole business. Companies like eZ live and die with their OSS product.
  • While providing an OSS product can give many benefits (community contributions, easy access to customers, publicity, etc). It is NOT necessarily simple to attract and sustain a community of volunteers and other organizations.
  • See: http://www.ez.no
  • See: http://www.itea-cosi.org
  • The company, and its products and strategy have evolved Architecture and business models 1999-2001: A re-usable web framework 2001-2005: Enabling plug-ins 2005 ->: Building a library
  • EZ have succeeded at attracting a community because they have had a product which is interesting and attractive. They have been able to provide the services that the customers need. They have also had a modular architecture which has allowed other to extend eZ's products.
  • While, eZ has made plans, we believe that some of their success is due to their agility and ability to adapt and change their business according to the opportunities which have surfaced. By “dividing” the community they have been able to strictly control core assets while being more open to contributions from the outside over, and under eZ Publish.
  • Other papers claim that the investments necessary for releasing and OSS product are considerable. However, through the eZ case we show that they can be relatively low. If one does not overdo everything from the start, the infrastructure(and the investments) can rather grow with the community and its needs.

OSS2009 Øyvind Hauge OSS2009 Øyvind Hauge Presentation Transcript

  • Providing Commercial Open Source Software: Lessons Learned Øyvind Hauge, Sven Ziemer [email_address] Øyvind Hauge and Sven Ziemer, Providing Commercial Open Source Software: Lessons Learned, in: Proceedings of the 5th IFIP Working Group 2.13 International Conference on Open Source Systems (OSS2009) - Open Source Ecosystems: Diverse Communities, June 3-6, Skövde, Sweden, pages 70-82, Springer, 2009 Doi: http://dx.doi.org/10.1007/978-3-642-02032-2_8
  • Lessons learned
    • Allow your business model to evolve
    • Balance control related to community contributions
    • Be part of your own community
    • Apply licenses which suits both you and your community
  • Context and problem
    • For-profit providers of OSS
    • How to succeed as an SME providing OSS?
      • The whole business may be tied to the OSS product
  • Motivations for providing OSS
    • Business rationale
      • Create market for other services
      • Get community contributions
      • Branding
    • In large companies it is often part of something more
      • Establish de-facto standard
      • Challenge competitors
  • Challenges providing OSS
    • Attracting and sustaining a community is hard
    • Must do most of the development themselves
    • Many stakeholders may want to be involved
    • Need for technical preparations and dedicated resources
  • The case – eZ Systems
    • 65 employees in Norway, Denmark, Canada, France, Japan, Belgium, and Germany
    • eZ Publish: PHP web content management system
    • Business model
      • Paid expansions
      • Maintenance and support
      • Partner program including certifications
      • Dual licensing
  • Research Design
    • Collaboration in the COSI project
    • Data collection over three years through
      • Interviews
      • Workshops
      • Project meetings
      • Project reports
      • Post Mortem Analysis
  • The eZ story
  • Community: Publish
    • Advantages
      • Reduced marketing efforts for services
      • Shorter sales cycles
      • Understanding of user needs
    • Code control: Strict
    • Community
      • Involvement: Good but could have been better
      • Contributions: Somewhat limited
    • Licenses
      • GPL
      • Three proprietary licenses
  • Community: Plug-ins
    • Advantages
      • Ability to extent creates closer ties to customers
      • Added value
    • Code control: None
    • Community
      • Involvement: Facilitator
      • Contribution: Significant
    • Licenses: Given by Publish's license
  • Community: Components
    • Advantages
      • eZ needs it
      • Contributes to the future of PHP
    • Code control: Open
    • Community
      • Involvement: Good, a technical community
      • Contributions: Significant
    • License: New BSD
  • Attracting a Community
    • Interesting product with a large group of potentially users
    • Provided the services the customers need
    • Modular/expandable architecture
    • Involving the community
      • Been active
      • Maybe too much control for Publish
  • Lessons learned
    • Allow your business model to evolve
    • Balance control related to community contributions
    • Be part of your own community
    • Apply licenses which suits both you and your community
  • Discussions
    • Infrastructure investments
      • Not considerable
      • Relevant for software providers but OSS providers
    • Layering the software and community seems beneficial