OSS2009 Øyvind Hauge


Published on

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

Published in: Technology, News & Politics
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • 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

    1. 1. 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
    2. 2. Lessons learned <ul><li>Allow your business model to evolve
    3. 3. Balance control related to community contributions
    4. 4. Be part of your own community
    5. 5. Apply licenses which suits both you and your community </li></ul>
    6. 6. Context and problem <ul><li>For-profit providers of OSS
    7. 7. How to succeed as an SME providing OSS? </li><ul><li>The whole business may be tied to the OSS product </li></ul></ul>
    8. 8. Motivations for providing OSS <ul><li>Business rationale </li><ul><li>Create market for other services
    9. 9. Get community contributions
    10. 10. Branding </li></ul><li>In large companies it is often part of something more </li><ul><li>Establish de-facto standard
    11. 11. Challenge competitors </li></ul></ul>
    12. 12. Challenges providing OSS <ul><li>Attracting and sustaining a community is hard
    13. 13. Must do most of the development themselves
    14. 14. Many stakeholders may want to be involved
    15. 15. Need for technical preparations and dedicated resources </li></ul>
    16. 16. The case – eZ Systems <ul><li>65 employees in Norway, Denmark, Canada, France, Japan, Belgium, and Germany
    17. 17. eZ Publish: PHP web content management system
    18. 18. Business model </li><ul><li>Paid expansions
    19. 19. Maintenance and support
    20. 20. Partner program including certifications
    21. 21. Dual licensing </li></ul></ul>
    22. 22. Research Design <ul><li>Collaboration in the COSI project
    23. 23. Data collection over three years through </li><ul><li>Interviews
    24. 24. Workshops
    25. 25. Project meetings
    26. 26. Project reports
    27. 27. Post Mortem Analysis </li></ul></ul>
    28. 28. The eZ story
    29. 29. Community: Publish <ul><li>Advantages </li><ul><li>Reduced marketing efforts for services
    30. 30. Shorter sales cycles
    31. 31. Understanding of user needs </li></ul><li>Code control: Strict
    32. 32. Community </li><ul><li>Involvement: Good but could have been better
    33. 33. Contributions: Somewhat limited </li></ul><li>Licenses </li><ul><li>GPL
    34. 34. Three proprietary licenses </li></ul></ul>
    35. 35. Community: Plug-ins <ul><li>Advantages </li><ul><li>Ability to extent creates closer ties to customers
    36. 36. Added value </li></ul><li>Code control: None
    37. 37. Community </li><ul><li>Involvement: Facilitator
    38. 38. Contribution: Significant </li></ul><li>Licenses: Given by Publish's license </li></ul>
    39. 39. Community: Components <ul><li>Advantages </li><ul><li>eZ needs it
    40. 40. Contributes to the future of PHP </li></ul><li>Code control: Open
    41. 41. Community </li><ul><li>Involvement: Good, a technical community
    42. 42. Contributions: Significant </li></ul><li>License: New BSD </li></ul>
    43. 43. Attracting a Community <ul><li>Interesting product with a large group of potentially users
    44. 44. Provided the services the customers need
    45. 45. Modular/expandable architecture
    46. 46. Involving the community </li><ul><li>Been active
    47. 47. Maybe too much control for Publish </li></ul></ul>
    48. 48. Lessons learned <ul><li>Allow your business model to evolve
    49. 49. Balance control related to community contributions
    50. 50. Be part of your own community
    51. 51. Apply licenses which suits both you and your community </li></ul>
    52. 52. Discussions <ul><li>Infrastructure investments </li><ul><li>Not considerable
    53. 53. Relevant for software providers but OSS providers </li></ul><li>Layering the software and community seems beneficial </li></ul>