Providing Commercial Open Source Software: Lessons Learned
Providing Commercial Open Source Software: Lessons Learnedyvind
Hauge, Sven [email protected]
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, Skvde,
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 rationaleCreate market for other services
Get community contributions
Branding
In large companies it is often part of something moreEstablish
de-facto standard
Challenge competitors
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.
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
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.
The case eZ Systems
65 employees in Norway, Denmark, Canada, France, Japan, Belgium,
and Germany
eZ Publish: PHP web content management system
Business modelPaid expansions
Maintenance and support
Partner program including certifications
Dual licensing
See: http://www.ez.no
Research Design
Collaboration in the COSI project
Data collection over three years throughInterviews
Workshops
Project meetings
Project reports
Post Mortem Analysis
See: http://www.itea-cosi.org
The eZ story
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
Community: Publish
AdvantagesReduced 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
LicensesGPL
Three proprietary licenses
Community: Plug-ins
AdvantagesAbility to extent creates closer ties to customers
Added value
Code control: None
CommunityInvolvement: Facilitator
Contribution: Significant
Licenses: Given by Publish's license
Community: Components
AdvantageseZ 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 communityBeen active
Maybe too much control for Publish
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.
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
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.
Discussions
Infrastructure investments Not considerable
Relevant for software providers but OSS providers
Layering the software and community seems beneficial
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
