Software Open-Source in ambito industriale:opportunità e rischi

Claudio Scordinoc.scordino@evidence.eu.com

Evidence Srl

Better Software 2011

Introduction

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

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

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

– Ubuntu ?

– Sun (acquired by Oracle)

Choose the right business model!

Open-Source licenses

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

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

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)

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

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

Reusing Open-Source code

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

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

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

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!

Releasing as Open-Source code

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

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

20

Releasing: some risks

• 1st issue: loss of strategic competitive advantage ?

– Evaluate the market and your main competitors!

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

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

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)

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

Summary

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.

27

Questions ?