Transcript of "Fundamentals of Using Open Source Code to Build Products"
Fundamentals of Using OpenSource Code to Build Products Brian Warner The Linux Foundation
The Linux FoundationLinux Foundation Confidential 2
The Linux Foundation is the center of Linuxdevelopment, legal defense and promotion 3
The Linux Foundation is Represented by Firms with Major Investments in Linux Platinum Sponsors Gold SponsorsLinux Foundation Confidential 4
The Linux Foundation is Represented by Firms with Major Investments in LinuxSilver SponsorsLinux Foundation Confidential 5
The Linux Foundation by the Numbers Ø 1 Linux kernel inventor – Linus Torvalds Ø 170+ Corporate members including IBM, Intel, Samsung, Oracle, NEC, Fujitsu, Qualcomm, HP, Red Hat, Canonical, China Mobile, Motorola, AMD, ARM, and many more… Ø 3,000,000+ visitors each month to our web properties Ø 15,000+ registered users on Linux.com Ø Thousands of individual members Ø Dozens of technical workgroups include the Tizen Project, Yocto Project, Long Term Support Initiative, Open Compliance Program, Linux Standard Base, Linux Printing, Legal Collaboration, etc. Ø 23 industry-leading training offerings Ø 14 Global Linux events – the “Who’s who of Linux”Linux Foundation Confidential 6
Members Create Workgroups to Collaborate with Other MembersDriver Backporting Open Source as Prior Art Kernel.org StaffGreen Linux Japan SI Forum Developer Travel FundDeveloper NDA Program IPv6 Workgroup Technical Advisory BoardLegal Defense HPC End User Council Linux Foundation Confidential 7
The Linux Foundation is at the center of theLinux Defense Network LINUX DEFENDERS Linux Legal Defense Fund 8
The Linux Foundation offers training andtechnical services 9
Fundamentals of Using Open Source Code to Build ProductsWhy do it?The (corporate) open source developmentmodelUnderstanding your obligations with opensource licenses
Open Source Software is ...A licensing regimenA collaborative development methodology: Ø Community develops, debugs, maintains Ø Usershave source code access and the right to adapt, distributeA way to reduce development costs andimprove qualityAn inexpensive way to distribute softwareAn inexpensive way to procure software 11
Incorporating open source componentsWhy do it?
Time to money is impacted by five major factors1. Time to produce a sellable product2. The cost to develop or acquire components3. Competitiveness of a product’s features4. The quality of the product5. Ability to provide a stream of updates
1: Time to Produce a Sellable ProductRule #1: Ø There is little value in reinventing the wheel (and it’ll probably make you late).Rule #2: Ø Evaluate external components. If the shoe fits, wear it.Rule #3: Ø Get it for free when you can.
A typical software stack can be partitionedinto two broad categoriesHeavy lifters Differentiators OS kernels Performance tweaks Web browser engines Applications UI toolkits Integration X servers Fit and finish Multimedia frameworks … Bluetooth stacks Telephony stacks …
Try not to reinvent the heavy liftersThey’re done.They’re mature.They’re open.(and your competitors are already using themto get a leg up on you.)
2: The cost to develop or acquire componentsAs of 2011, it would cost at least $3B to developthe Linux kernel from scratch.On average, 7.21 patches are accepted into thekernel per hour.
2: The cost to develop or acquire componentsThe amount of combined effort going into opensource “heavy lifters” is astonishing.We call this the leveraged development model.
2: The cost to develop or acquire componentsYou can work against it, or you can work with it.
2: The cost to develop or acquire componentsDid I mention it’s free?
3: Competitiveness of a Product’s FeaturesLess time spent on heavy lifting means: Ø More time spent on competitive differentiators § - Or - Ø Competing in-market sooner with the differentiators you already haveHeavy lifters are (usually) continually improved Ø …and often by someone else.
4: The Quality of Your ProductLinus’ Law: Ø “Given enough eyeballs, all bugs are shallow.”
5: Ability to Provide a Constant Stream of UpdatesThanks to these two phones… …consumers in all industries are far more aware of system software updates than ever before.
Updates are hardHas your development talent shifted to newproducts?Do you have time and resources to backport?Will the features be competitive enough toinstill brand loyalty?
These are real issuesThere is no silver bullet, but it helps when thecode base hasn’t been static.-longterm stable releases were created toaddress this problem.LTSI is a kernel specifically for CE devices.
Understanding the (typical) corporate open source participation modelWhen should you tap into an ongoingdevelopment process?How do you balance short and long term value?Do you need to contribute back?Can you effectively manage your licensecompliance obligations?
When do you pull code?Continuous integration and testing is ahallmark of many open source projects.Features are often submitted early and stabilizeover time.Roadmaps are not binding.
When do you pull code?First, understand the cycles.
Open source development model User Community Project or Feature Ideas Architecture and Feature Requests Design Discussion (submitted by developers and users) Implementation (coding) Patches (submitted by developers and users) Continuous Testing Deployment and Integration (release)DeveloperCommunity Test Projects to Automate Maintenance Testing and Validation
The open source release cycle Validate Build Generate Integrate QA Build patch with -dev validation Release Debug Submit Validate validation Feedback Loop Publish as Write code -stable Check out code Setup machineDriven by participating developers Driven by maintainers
How to understand the cyclesResearch a project’s historical release cycles.Subscribe to project mailing lists.Identify maintainers, and what makes them tick.Bug/feature trackers often have futuremilestones.
Balancing short and long term valueProduct development is a journey, not adestination.
This is not always a viable pathThe way your differentiators interact with heavylifters will change over time. Ø New or deprecated features in upstream heavy lifters § Or - Ø API changes § Or - Ø Customer requirements § Or - Ø …Ask Google…
So… what then?The current industry best practice is to balanceconsumption with upstreaming.Choosing what goes upstream is an art not ascience, but it’s usually the heavy lifters.Upstreaming is not a requirement (though it is agood way to save money and gain respect).
Don’t confuse upstream contribution with license complianceUpstreaming is a development strategy.License compliance is a legal requirement.(but contributing upstream is a good strategy tomeet most compliance obligations)
Speaking of license complianceThat sounds all legal and stuff…
Standard DisclaimersThe presenter is not a lawyer and none of thematerial discussed or presented should beconsidered as legal advice.Please consult with your corporations counselfor your specific situation. 42
What Makes a License an Open Source License?The Open Source Initiative formulated an “OpenSource Definition” (OSD) to define the criteriathat a license must meet to be considered“open source” Ø Free redistribution Ø Availability of source code Ø Right to modify Ø No discrimination (against users or uses) Ø Self-perpetuating terms and conditions 43
What is “Open Source Compliance?”Open Source Compliance refers to the aggregate of Ø Policies Ø Processes Ø Training Ø Toolsthat enables an organization to effectively use opensource software and contribute to opencommunities while Ø respecting copyrights, Ø complying with license obligations, and Ø protecting the organizations intellectual property and that of its customers and suppliers. 44
When do I need to think about compliance?If you are distributing code covered under anopen source license.
Define “distributing”“Distributing” typically means transferringcontrol away from yourself or your company. Ø (but ask your corporate counsel)Internal use code is sometimes distributeddown the road, so it should be considered too.
Generally speaking, what’s an obligation?Depending on the license(s) involved, obligationscould consist of: Ø Inclusion of copyright and license in the source code and/or product Ø documentation or user interface, so that downstream users know the origin of the software and what their rights are. Ø Disclaimers of warranty on behalf of the authors Ø Notices as to source code availability – for original work, for combined work or modifications, and so on Ø Etc.Your corporate counsel needs to interpret this foryou.
Individuals Worldwide Commit Themselves to Compliance ActivitiesFrom the September 26, 2010 NY Times:http://www.nytimes.com/2010/09/26/business/26ping.html 48
Managing an effective compliance programLegal lays the ground rules (interpretation,combinations, blessed/banned licenses).Everything else is logistics.
Managing an effective compliance programLogistics is probably >90% of the work.
Compliance in a nutshellKnow what license combinations are approved.Have a consistent process for rapidly approvingnew components.Keep detailed records of what you do to thecomponents you ship.Fulfill the obligations of the license.Be prepared to respond to inquiries efficiently.
There are a lot of resources out therehttps://www.linuxfoundation.org/publications/compliancehttp://www.softwarefreedom.org/resources/
ConclusionOpen source is effectively springboarding thecompanies whose engineering and managementorganizations know how to use it effectively.There’s a lot of money to be made and saved.Complying with open source licenses is reallyimportant.Compliance is an ongoing process.When in doubt, find your lawyers and ask them.