3. My background...
• My name: Claudio Scordino
• Education:
– 2003 Master degree in Computer Engineering
– 2007 PhD in Computer Science
• Work:
– 2006-2008: Linux kernel developer at Evidence Srl
• 2008-2010: Code merged in the mainline Linux kernel
– 2008-2011: Project Manager at Evidence Srl
• 2011: ScrumMaster certification
Evidence Srl: we make firmware and software for embedded,
real-time and complex systems
3
4. Outline
• Open Source and the business model
• Overview of the most common open-source licenses
• Reusing existing open-source code
– Opportunities
– Risks
• Releasing our code as open-source
– Opportunities
– Risks
• Summary
4
5. Open Source and the business model
• Open-Source does not mean "no money"
• Several companies make money working with Open-Source
projects. Examples:
– Google (Android, Googletest, Chrome, etc.)
– Redhat, IBM
• Other companies, instead, had troubles with their strategy:
– Nokia
– Mandrake/Mandriva
Choose the right
– Ubuntu ? business model!
– Sun (acquired by Oracle)
5
7. Open Source licenses
• Several Open Source lisenses exist
– See http://www.opensource.org
– See http://www.gnu.org/philosophy/license-list.html
• Big differences between one license to another
• We will see three major open source licenses:
– GPL
– LGPL
– BSD
7
8. GNU General Public License (GPL)
• Most popular license
• Published by the Free Software Foundation
• Allows to modify and redistribute (even sell) the code as long as
the recipient maintains the same rights (access to the source
code included)
• No warranty
• Modifications are and remain GPL
• Examples: Linux, U-Boot, Firefox
8
9. GNU General Public License (GPL) (2)
• In practice:
– The source code must be released to the end-user, if any
• No obligation to release the source code to anybody else
– GPL code cannot be used inside non-free code
• Use of GPL libraries in non-free programs is forbidden
(unless code is for "personal usage" and not distributed)
• Several versions available:
– GPLv2:
• The most used (e.g., Linux and U-Boot)
– GPLv3:
• Latest version
• More restrictive (forbids deals about patent protection, hardware lock
technologies and DRM)
9
10. GNU Lesser General Public License (LGPL)
• Published by the Free Software Foundation
• Usually used for libraries
• More permissive than GPL: code can be linked to proprietary
programs
– The program linked to the LGPL code can be distributed under
any chosen terms
• The recipient must be given the possibility of linking the program
to a modified or newer version of the LGPL library
– This restriction is unacceptable in some circumstances, so
some projects prefer the GPL with linking exception license
• No warranty
• Examples: GTK and Qt libraries, Erika Enteprise RTOS
10
11. BSD licenses
• Family of licenses
• Used for BSD by the Berkley university
• Redistribution in binary form is permitted
– It only requires to acknowledge the original developers
– More permissive than GPL and LGPL
• No warranty
11
13. Reusing: the appealing opportunities
• Re-using existing open-source code presents a set of appealing
opportunities:
– Faster development with respect to code written from scratch
– Lower costs (e.g., no royalties) with respect to commercial
solutions
– Lower (but not null) development costs
– Free help and technical support by a development community
– Possibility of having "branded products" (e.g., Android-based
cellphones)
• Success stories: mobile manufacturers using Linux, Android, U-
Boot
13
14. Reusing: some risks
• 1st issue: legal issues
– E.g., Must your source code be redistributed ?
– Read the licence carefully and think of all the possible
scenarios to understand any possible legal issue.
– In case the source code must be redistributed, you get all
opportunities and risks of releasing your code as Open-
Source. See the next part of the talk.
• 2nd issue: Lack of full knowledge of the system
– Problem shown when unexpected behaviors/bugs happen
– Remember that code may have not been properly tested
– Allocate one full-time person to deeply study the software
14
15. Reusing: some risks (2)
• 3rd issue: are you enough agile ?
– Open-Source projects are characterized by rapid development
cycles
• On the Linux kernel, on average, 7267 lines of code added every day
– "Old-style" companies can have troubles in following a fast
development cycle
• Usually because the amount of effort has been underestimated
– Allocate one full-time person to keep in touch with the
development community and to follow the development cycle
15
16. Reusing: some risks (3)
• 4th issue: how much being updated ?
– Fix bugs and security holes as soon as possible
• When facing a problem/bug, synchronize with the latest version
before asking help to the development community
• Consider letting people hacking the device when this is not a real
problem (e.g., cellphones)
– Suggestion: when a stable and working system is reached,
evaluate if being aligned with the next versions is the right
choice
• Regressions are likely to happen and for mature products it's not
worth the trouble!
16
18. Releasing: interesting opportunities
• Releasing our code as Open-Source can have a set of advantages
as well:
– Create a development community that can provide help and
support for free
– Better code: more people review and improve the code
– Lower development/maintainance costs
– Boost collaboration with other research institutes or other
companies, reducing the effort/costs
– Enter new markets: change your business model from product
to service to enter a market characterized by closed-source
products
18
19. Releasing: interesting opportunities (2)
– Customers of a software product have more trust: they get
the source code to be able of fixing possible technical issues
even in the long term
– Positive image of the company
• Example: Google
• Free advertising
• Easier to hire talented developers
19
20. Releasing: some risks
• 1st issue: loss of strategic competitive advantage ?
– Evaluate the market and your main competitors!
20
21. Releasing: some risks (2)
• 2nd issue: decide how to drive your business model:
– Often this implies changing from product to consultancy
– Think about using a dual-license model to investigate if it is
possible to have advantages of both worlds (i.e., commercial
and open-source)
• Good way to explore the market and to evaluate the strategy
– Remember that once the source code is public, it is possible
to go back but somebody could start a fork of the project
21
22. Releasing: some risks (3)
• 3rd issue: future legal issues
– Choose the right license carefully and think of all the possible
scenarios
– Choose one of the major existing licenses
• Developers are afraid of licenses they don't know
• Trying to inventing a new license is risky, because it requires a deep
knowledge in this topic
22
23. Releasing: some risks (4)
• 4th issue: evaluate the amount of effort needed
– Coordination and collaboration with the community:
• Consider time/effort to involve new developers through
documentation, wikis, forums, and mailing lists.
– Maintainance and technical support
• Especially in the beginning phase, allocate a full-time person to
answer technical questions and help people to get involved
– Remember that developers stay away from projects that
appear to be dead
• The amount of "activity" of a project is evaluated through different
metrics (e.g., number of emails/commits)
23
24. Releasing: some risks (5)
• 5th issue: how much to drive development ?
– If you do not enforce a direction, you may experience the loss
of full control on the development
– If you try to drive the development in a different direction
than the one wanted by the community, there is the risk of a
fork
24
26. Summary
• Reusing Open-Source software in your product can really cut the
development costs. However:
1. Read the license carefully and evaluate all possible scenarios
2. Remember to allocate at least one person full-time to study and test the
software and to follow on-going development
3. Fix bugs and security holes immediately
4. For mature and stable products, don't jump to new versions
• Releasing your software as Open-Source may reduce development
costs and improve your company's image. However:
1. Evaluate your new business model and if you are losing competitive
advantage
2. Consider the effort for making documentation, wiki, forums, and mailing
lists.
26
