The Business Obligations of Open Source Software

This article is a part of a series on using open source in business:

The previous two articles in this series covered the technical and business benefits OSS offers. However, this only paints half the picture. While OSS might be free to use, modify, and distribute, it doesn’t come without effort and risk; if a company isn’t prepared to handle them, they can cause significant headaches down the road. This article will provide an overview of the obligations and risks a company that uses OSS in their products or services must be aware of.

Licensing and Compliance

While OSS has no initial licensing costs, this doesn’t always mean you’re free to use OSS however you want. Open source licenses can impose a range of obligations that must be satisfied whenever code that includes OSS is distributed in a product or service. This can include things like disclosure requirements, specific notifications, and licensing modifications under the same open source license.

At the very least, all businesses need to maintain an accurate inventory of all OSS that’s used in their products or services, and must have adequate processes to ensure compliance with all licenses both during and after product distribution. Typically, a single person is assigned the responsibility of being the open source compliance manager to oversee the execution of this, and it requires coordination between legal, engineering, human resources, and the compliance officer; larger companies often need to establish an Open Source Review Board to facilitate this coordination.

The most critical coordination is between product, engineering, and management teams: they must identify all OSS used in product code and to assist with any licensing or compliance questions. This often means employee roles need to be expanded to cover the various elements of OSS compliance that directly relate to each position. This coordination must also expand outside the company to include software providers as well because any OSS that’s included in the software they provide must also be properly accounted for and complied with. While establishing a framework for this coordination, it’s common to come across areas that need better tooling which creates more need for deployment and training.

Open source licensing can create substantial obligations, especially in larger organizations, and these obligations require more coordination between various teams. This article only briefly touches on the subject of open source compliance, and if you’re interested in this subject more there is a lot of detailed information on the web.

Training and Development

Training is a critical component of open source engineering because you’ll need to train developers, legal, software procurement, quality assurance, systems administrators, and others on the obligations of open source compliance. Additionally, you might need training for developers that have little to no experience working with an open source community on how open source development works.

Maintenance and Support

Proprietary software typically includes some level of paid support from the vendor company, which may include an SLA, pre-disclosure of vulnerabilities, or implementation support.  This is generally contractually enforceable, and it’s reasonable to demand responsiveness from the vendor in line with your support contract.  Similar support for OSS projects may be offered by companies participating in the ecosystem, but it is rare to find unpaid guaranteed support from the development community itself.  As most of the participants are either working on their own time or on behalf of an employer, it is neither reasonable nor fair to expect the same level of service as provided by a paid vendor.  As such, it may be the case where businesses that incorporate unpaid OSS into their products are responsible for installing updates and implementing security fixes and new modules themselves.  These tasks are easy to push aside in favor of more pressing issues, but they must be addressed nonetheless because a lack of maintenance can rapidly overcome the benefits of incorporating externally developed code.

To reiterate, OSS does not include any sort of support contract unless it is specifically negotiated with a third-party company that offers these services.  The most common OSS licenses specifically include a disclaimer of warranty.  If a business requires 24/7 support for services that use OSS, this will either need to be negotiated with an appropriate third-party company or the team will need to be hired in-house. Support services are a critical, but often overlooked, investment when using OSS.

Application Dependence

OSS can be a great avenue to avoid proprietary software dependence, but that doesn’t mean it’s a simple process to migrate away from OSS that no longer meets the requirements of a company. Whenever OSS is used for business-critical applications, the business becomes dependent on the community and project.  Changes that go against the interests of the business could result in the company needing to migrate to an alternative. The effort required to make this switch can vary widely depending on the availability of expertise and the maturity of the projects being migrated between. OSS community support can mitigate this problem, but this also varies substantially from project to project.  In general, it is considered a best practice to be actively engaged with and support select OSS communities to reduce the risk of unexpected changes to critical components.

Strategic Dependence

Open source leadership can bring substantial benefits to companies that properly leverage it, but the independent nature of open source communities can complicate strategic decisions. For starters, open source community choices may preclude downstream requirements, particularly if a company does a poor job of communicating with the upstream community.  This can introduce added effort to maintain downstream products. Additionally, if the community doesn’t have a formal technical roadmap, planning can become much more complicated. Finally, all software whether open or proprietary fits onto a spectrum of maturity, and this can often reflect the needs of a community.  For example, software developed for home use or for academic research may require some level of investment to meet product security requirements.

Do the Benefits of Open Source Outweigh the Obligations?

This article should have provided you with a general understanding of what obligations and risks are associated with the use of OSS in a product or service. There is no one-size-fits-all solution for whether a company should use OSS or simply buy software from a proprietary vendor, so it’s always important for any business that’s considering the use of OSS to consider their own specific requirements.  However, the overwhelming trend in the industry has been in favor of OSS components wherever possible, particularly in consumer electronics.

Here are some questions all businesses should ask themselves when considering the use of OSS in products.

  • How do the platform costs of OSS compare to similar offerings?
  • What commercial support offerings are available?
  • What license obligations does the code have? Does our company have the resources to fill them?
  • Who are the key individuals and organizations in the open source community? How long have they been around?
  • Do the open source community goals and roadmap meet our risk profile?
  • Does our company have adequate resources to support the use of OSS in our products?


Now Hiring: Open Source Cloud Engineers

The cloud is ripe with open source software as the collaborative development model has proven to be extremely effective at commoditizing much of the software stack. Today, foundations like the Cloud Native Computing Foundation are bringing together numerous companies to collaborate on vital, cutting edge technology, and open source software is doing what it has done in many other industries as it positions itself to be critical to the adoption of cloud technologies. More companies are launching open source initiatives to improve this technology domain and the Open Source Group recognizes this as a valuable place for us to increase our breadth of impact on Samsung’s innovation.

We’re Hiring Cloud Experts!

With this said, we’re pleased to announce we’re hiring multiple positions for experts in open source cloud technologies to help us in our mission to improve Samsung’s understanding and adoption of open source software. Here are the most important skills we’re looking for:

  • Programming experience in one or more languages, including C++, Go, Python, Shell, C#, Ruby, JavaScript, and PHP. Please note that the language competency depends on the project you’re expected to get involved in.
  • Expertise contributing to one or more of these projects: Kubernetes, OpenTracing, Jaeger, Envoy, Linkerd, gRPC, Fluentd, and related CNCF projects.
  • Knowledge of distributed tracing, monitoring, service management, and container orchestration.
  • Demonstrable experience participating in open source communities as a contributor, committer, or maintainer.
  • A history of providing technical leadership within open source communities and engaging in political influence and guidance.
  • A high degree of self-motivation and the ability to work alone, managing your own work and setting sensible priorities.
  • Background in pipeline operations, packaging and deployment of cloud applications, virtualization technologies and API’s,

However, don’t worry if you aren’t experienced with all of these skills; the most important skill you can have is the ability to expand your own technical knowledge to meet the rapidly changing open source software ecosystem. If you have knowledge of any of these items with a history of good open source contributions, we want you!

Why Work for Us?

You’ll want to work for us if you’re interested in:

  • Spending 100% of your development time on upstream open source projects,
  • Working from almost anywhere in the world (as long as you have an internet connection),
  • Using your preferred infrastructure for your development environment,
  • The freedom to work outside the pressure of product deadlines, and
  • Improving your visibility with open source communities via participation in project governance and events.

If you’re someone who’s passionate about open source software and deeply knowledgeable about the things mentioned in this post, we’d love to hear from you. If you’re interested, send us a message on twitter @SamsungOSG or an email to hiring[at] If you want to learn more about our team, check out this blog post that explains why our team was created.

We look forward to meeting some great open source engineers!

The Business Value of Open Source Software

This article is a part of a series on using open source in business:


This article will explore how OSS can benefit a business from a non-technical perspective.

Open Source Development Reduces Costs

One of the major reasons more companies are adopting OSS is because it is a very effective way to reduce development costs. The two primary ways open source reduces development costs is by simplifying software licensing and increasing development speed.

Simplifies Licensing

Initially, the most obvious place OSS reduces costs is through the complete lack of licensing costs. Proprietary software typically includes initial licensing costs and ongoing maintenance contracts that can be a significant portion of the initial costs; these are often unavoidable. OSS licenses grant free use, modification, and distribution rights to everyone, meaning there is no initial costs to licensing the software, and maintenance can be customized to the needs of the specific business.

OSS also has a lower cost associated with the software procurement process since the OSS can simply be downloaded for experimentation or research, with no requirement to negotiate procurement with a proprietary vendor. Finally, OSS licenses allow a much broader range of use and customization, sometimes unlimited, this usually needs to be negotiated in a contract with a vendor in the case of proprietary software.

Increases Development Speed

In an OSS project, code functionality can be modified whenever necessary, with no need to negotiate custom contracts or statements of work with third-parties; this alone can result in significant improvements to development speed and reduce the amount of time to deploy products or services.

Any contributions that are successfully committed upstream will ultimately reduce the amount of effort required for ongoing maintenance. Once a maintainer has deemed code worthy of being included upstream, they usually do so with the implicit understanding they will maintain its functionality in the project unless something else is specifically agreed upon. Of course, there are limits to this, and the maintainer may eventually decided the functionality doesn’t comply with project requirements in the future; this may result in the code being dropped if no contributors step up to maintain its place in the source code.

Additionally, open source communities typically produce a faster evolution of upstream software that’s based on the features the community needs rather than financial motivations. The release early, release often strategy of most open source communities results in regular updates that allow anyone to take advantage of new features as soon as they’re available while also monitoring changes to experimental versions to be prepare downstream software to accommodate upcoming changes to stable versions.

The Strategic Value of Open Source

OSS has value that goes beyond the company’s bottom line; it can also be an effective route for creating strategic value. The two major ways it accomplishes this is through an avoidance of vendor lock-in and the ability to influence the direction of vital software through technical and political leadership.

Avoid Vendor Lock-in

A proprietary vendor might limit their software’s compatibility with competing services to elevate their prices. This can lead to any companies who rely on this software to face extremely high costs to migrate away from proprietary software which puts them at a disadvantage in contract negotiations.

OSS development encourages compatibility with more formats and software because it improves the functionality of the software: the primary goal of the developer community. Additionally, the ease of adaptability to niche use cases tends to make OSS compatible with a much wider range of complimentary software.

The primary benefit of this is that it mitigates the risk of upstream software discontinuation. Proprietary software vendors might discontinue a product, get purchased by another company with different business motivations, or go entirely out of business. Any of these scenarios can result in a sudden and expensive switch to new software.

On the other hand, OSS code is not generally owned by any single organization or individual, and anyone can pick up the reins to keep the project going. While this sudden changes in leadership for an OSS community still have costs for companies that rely on the code, adopters will have more options and flexibility for dealing with these changes. For example, an affected company could decide to adapt to the new direction of the project, or fork the project if the new direction conflicts with the company’s requirements.

Create Technical and Political Leadership

Open source community leadership provides an avenue to ensure important software remains viable to a company, while also ensuring the they have a voice in community decisions.

Open source leadership must be earned through an ongoing participation in the community, and is something that can be lost due to a lack of participation. Achieving OSS leadership takes persistent effort over an extended period of time, but the benefits often outweigh the costs.  Typical reasons to go through this process include a desire for improved visibility in external developer and user groups, and gaining technical influence over the direction of important projects.

A major benefit of open source leadership is that it can be leveraged to grow internal open source competence by promoting open source best practices and transferring knowledge of open source components to internal teams. Finally, engineers who dedicate time to upstream contributions improve the ability of product teams to use open source, making it easier for them to directly maintain and improve the OSS components they rely on.

The Rosy View of Open Source

The Business Value of Open Source Software - OSS-Business-Value

After reading the last two articles in this series, you might think OSS is nothing but sunshine and flowers with all the benefits it offers. These benefits might be pretty big, but they also come with significant risks and obligations any company that uses OSS needs to be aware of.  The next article in this series will cover these risks and obligations.

Join Us for the Tizen Developer Conference in San Francisco

The Tizen Developer Conference (TDC) is just around the corner; it will be held May 16 – 17 at the Hilton Union Square Hotel in San Francisco, CA. Our team contributes a ton of code to some of the critical open source software that makes up Tizen, so of course we’ll be spending some time there to network with app developers and device makers who work with Tizen.

What’s Happening with Tizen?

There has been quite a few exciting developments for Tizen over the last year; for starters Samsung joined forces with Microsoft to bring .NET to Tizen, allowing developers to build applications for Tizen using C# and Visual Studio. Additionally, Tizen has continued to show up on a growing number of consumer devices including the Gear S3, Z2Gear 360, AR9500M air conditioner, POWERbot VR7000, multiple smart TV’s, and more. Finally, Tizen RT was released last year, making it easier than ever to run Tizen on low-end devices with constrained memory requirements. All of these changes create a great environment to see some interesting new things at this conference.

These developments have made Tizen more accessible than ever for app developers and device manufacturers; now is a great time to get more deeply involved in this ecosystem. Take a look at the conference sponsors page to get an idea of what companies will be at TDC to show off their latest work.

What to Expect at a Tizen Event

TDC is a technical conference for Tizen developers, app developers, open source enthusiasts, platform designers, IoT device manufacturers, hardware and software vendors, ISVs, operators, OEMs, and anyone engaged in the Tizen ecosystem. It offers an excellent opportunity to learn from leading Tizen experts and expand your understanding of mobile, IoT, wearable tech, and IVI systems engineering and application development; events like this are the best way to network with the top companies working within the Tizen ecosystem.

Not to mention, Tizen events often include the unveiling of new devices, so visitors get to be some of the first people in the world to see the next greatest things for Tizen. The real cherry on top are the giveaways that accompany some of these announcements. Winning a new device more than makes up for the cost of admission :-)

Last but not least, the most valuable component of these events are the technical sessions that provide practical knowledge to help build better devices and apps. There are four session tracks to choose from:

  • Device Ecosystem – Learn how to create new devices with Tizen.
  • Application Ecosystem – Learn how to build apps for Tizen with .NET, Xamarin.Forms, Visual Studio, and more.
  • Platform Core – Learn about some of the platform components that make Tizen great for various use cases.
  • Product Experience – Learn about some of the interesting Tizen features that are being used to make products better.

TDC will conclude with an IoT hands-on lab that will provide training for using Tizen RT and ARTIK devices to build IoT products. This requires separate registration, so make sure to bring your laptop and coding skills so can take part in this wonderful opportunity to learn from experts.

Check out the entire conference schedule here.

What are You Waiting For?

Time is running out to plan your trip to this conference. Students can register for free (don’t forget your student ID when you come), and for everyone else, you can use the coupon code TIZSDP to get 50% off your registration fee. If you’ll be in the San Francisco area on May 16 and 17, don’t miss out on this great opportunity. Check out the registration page to learn more about attending this conference.

We hope to see you there!

How OCF is Creating the Connected Car

The Connected Car & Fragmentation

Traditional car manufacturers have begun including early iterations of touchscreen technology with access to media and apps that can also provide basic HVAC (Heating, Ventilation and A/C) controls for the vehicle. These features can often be accessed through mobile devices with tailor-made apps from each car maker. However, this has led to OEMs building their own ecosystem silos, similar to the trends observed in the smartphone industry. The lack of an open, standardized framework has resulted in a fragmented market, where experiences from one OEM won’t work with another in any streamlined way; consequently, developers aren’t thinking about how to provide a rich user experience that allows cars and drivers to work in unison; this is a huge missed opportunity.

Samsung OSG, OCF, and IoTivity

The Open Connectivity Foundation (OCF) is creating a specification and sponsoring the IoTivity open source project to deliver an open and secure connectivity and interoperability framework; this enables devices from multiple vendors that belong to multiple vertical domains to run on a variety of software and hardware platforms. Automotive is one key vertical where OCF can have a significant impact. The Samsung Open Source Group (OSG) has been playing a significant role in both the Open Connectivity Foundation (OCF) and IoTivity.

Collaboration with Genivi & W3C

The GENIVI Alliance, a community that’s developing open source software and standards for the connected car, and OCF are partnering to co-develop open standards for vehicle connectivity and vehicle data exchange, including a unified model for secure discovery and exchange of information between smart homes, connected cars, and other IoT devices. The joint effort will also address end-to-end security challenges to enable new opportunities across multiple verticals. Additionally, GENIVI and OCF will  closely collaborate with the W3C Automotive Working Group, which develops the Open Web Platform API specification to expose vehicle data to web application developers.

Proof of Concept

Through a broad collaboration spanning ten organizations, we were able to develop and showcase our demo at the OCF booth at CES 2017.  ETRI, Genivi Alliance, Honeywell, Intel, Jaguar Land Rover, OCF, Samsung, Tinnos, The Data Alliance, and W3C all collaborated on open specifications and open source software to realize numerous interesting connected car use cases and explore interoperability between smart home devices and the connected vehicle.

Source Code

If you are interested in recreating these demos, or would like to experiment with it, base of demo code have been shared on the Samsung OSG git repository. To get started with IoTivity on GENIVI, simply add the “meta-ocf-automotive” layer, which includes minimalistic examples that demonstrate IoTivity. You can use the following as a guideline, for Yocto based distros.

# Fist Setup yocto buildenv, then
git clone 
cd genivi-dev-platform 
git clone 
MACHINE=qemux86-64 # Or supported BSPs (raspberrypi, minnowboard, dragonboard...)
echo 'BBLAYERS += "${TOPDIR}/../meta-ocf-automotive"'  >> 'gdp-src-build/conf/templates/' 
source ./ $MACHINE bitbake genivi-dev-platform

Once booted on qemu or the Raspberry Pi 2/3, an IoTivity server can be started from “/opt/iotivity-example*” and example clients can be run on the same LAN, including localhost. These examples are part of our IoTivity example, and are ready to be forked to create your own IoT services. We hope it will inspire you and simplify integration; start learning! For support, check out the detailed instructions on IoTivity’s automotive wiki page. Since GENIVI’s development platform is now shipping iotivity-node, linking sensors to the cloud as shown at FOSDEM, can be done in a jiffy.

Working together across organizational boundaries has enabled us to realize these demonstrations with real devices that run open source software; hopefully this will help people understand the potential business opportunities of connected cars. Feel free to post a comment below if you have any questions or comments.

Additional Resources

[wp_biographia user="pcoval"]

[wp_biographia user="sanjeev"]

The Technical Value of Open Source Software

This article is a part of a series on using open source in business:

Technical value is one of the most important traits of software development and engineering. A mature open source community will often have multiple companies, organizations, and individuals who contribute to and depend on the code base. Any groups that depend on the code are invested in the future of the code, making it much less likely for the code to disappear while simultaneously encouraging participants to play an active role in ensuring proper bug and security fixing processes. This article will explore the ways open source software can benefit a business from a technical perspective by offering improved code stability and greater control over the software stack.

Open Source Improves Code Stability

Software built by a proprietary component provider can typically only be fixed by employees of the vendor company. In an open source community, anyone can test or fix bugs, regardless of association, and contribute to the reporting and tracking of bug fixes; as a result, there are many more avenues for errors in open source code to be discovered. This concept forms the core of Linus’s Law: “given enough eyeballs, all bugs are shallow.” Essentially, this states that when there are more tester’s and developers working together, bugs should be identified more quickly with more people who are capable of addressing them.

Anyone who identifies a bug with open source software can either fix it themselves, or inform the community of the problem in hopes that it will be fixed by someone who has a common interest. Proprietary vendors make commercial and financial evaluations before they implement security or bug fixes; there might not be enough financial incentive for them to make the specific fixes you require and creating this incentive can be extremely costly. Bugs in proprietary code can typically only be found through indirect methods, such as by encountering them while using the code in another product or service. On the other hand, OSS can be evaluated directly which makes it possible to find bugs before the software is even used.

The benefits of OSS for security are much more challenging to completely evaluate because open source vulnerabilities are often highly publicized, whereas proprietary software vendors can rely on security through obscurity since they distribute object code rather than source code. Because of this, bugs and security issues tend to be addressed much more quickly in open source communities with one major caveat: it hinges on the community having adequate bug and security vulnerability reporting and patching practices. There have been multiple high profile security vulnerabilities in OSS, including Heartbleed, which went unnoticed for years as it was deployed in numerous systems all over the world. In recent years, the security practices of OSS have come under much more scrutiny, resulting in the formation of groups like the Core Infrastructure Initiative, which seeks to identify critical open source components and ensure security is given adequate attention.

Ultimately, proper bug fixing and security practices come down to human ability and processes. Proper bug fixing and security auditing processes in an open source community can create code that is exceptionally secure and the high level of transparency open source offers makes it possible to evaluate the community directly. Many communities have formally defined processes for identify bug fixes or security flaws and patching them, all of this can be verified externally which isn’t possible with proprietary software. Finally, all OSS can be built from source code which improves security in cases where object code distribution is a concern.

Open Source Improves Control of the Software Stack

Another major technical benefit of OSS is having improved control of the software stack by means of a relatively unlimited potential for customization, and better knowledge-base of resources and information. Proprietary vendors can restrict the customization of their software and require expensive contracts for customization services. On the other hand, integrators can adapt OSS to meet the needs of anyone.

Mature open source communities often have numerous experts who can be relied upon for customization, whether it be through volunteered effort as a result of a shared interest, or by being hired directly to make the customizations. Since anyone can acquire OSS for learning purposes, there tends to be a much more broad and diverse ecosystem of developers and engineers. Additionally, since open source code is typically built in a modular fashion and governed through a maintainership system, it’s often much easier to find the items that need to be tweaked in the code and to make the required modifications.

One specific example where OSS is much more customizable than proprietary software is in language translations. Since all code is open to the public, anyone who is capable of translating between two languages can adapt the software for their specific language. This allows OSS to be translated to niche languages that might not be cost effective for a proprietary software vendor.

One final way that OSS improves control of the software stack is in the availability of a detailed knowledge-base of information. Proprietary vendors can restrict learning resources for their software however they want, but OSS tends to have a much more robust selection of supporting knowledge material that can be used to build in-house expertise. These resources can include things like wikis, project websites, and forums that provide general information for users and developers, as well as resources that allow individuals to get into direct contact with project experts like mailing lists, chat rooms, and question boards.

The Technical Value of Open Source Software - OSB3-tools-v2-1.png

Leveraging the Technical Benefits of Open Source

This article should have explained some common technical justifications for why OSS often provides better flexibility than proprietary software. In summary, it provides product creators:

  • The freedom to fix any bugs or security flaws that are identified,
  • A transparent process for identifying and fixing bugs and security flaws that can be verified externally,
  • More options for customization, with a more diverse ecosystem of developers and users, and
  • An improved knowledge-base that is publicly accessible.

The next article in this series will explore the ways OSS can benefit a business by simplifying licensing, increasing development speed, and reducing vendor lock-in.

Check Out the Free Open Source Compliance Handbook

Open source compliance is often overlooked, but is a critical component of a successful open source software strategy. If your company is going to use or contribute to open source software, failure to comply with the software licenses can lead to costly cleanup efforts, or even lawsuits if license violations are found. To mitigate these risks, it’s important to establish an internal organizational program that manages compliance with open source licenses.

For many companies, open source compliance is often the first major step into open source engineering, so it’s vital to establish proper organizations and procedures that build a foundation for continual success. That’s why Ibrahim Haddad joined forces with the Linux Foundation to create Open Source Compliance in the Enterprise, and released it as a free handbook to download.

This book covers the essentials of establishing a successful open source compliance strategy in an enterprise setting, including the structure of an open source management program, common processes and tools for compliance, how to train and encourage developers to follow compliance processes, when and how to involve legal experts, and more.  Many of these strategies are employed here at the Samsung Open Source Group and have helped us establish ourselves as a valuable asset to Samsung’s success. If you oversee a team of software engineers who work with open source software, this book will provide a wealth of helpful information; you should give it a read!

How I Learned to Stop Studying Architecture and Love Free Software

After finishing high school, I was destined to continue my academic life studying one of the fine arts I always loved: Architecture. I took special art classes to get prepared to study it, and so I did; I entered the architectural school at my hometown in the Canary Islands.

In their first year, all students learn about the Bauhaus school and their impact. I knew about them, but in that year I learned about their philosophy in detail and I became sanely obsessed with their work. During their difficult social/political time, Bauhaus revolutionized the world of architecture, design, and art. Their modernist designs were centered in functionality, simplicity, rationality, and taking art to everybody through mass production. In summary, making our day to day habitats and tools better, cheaper, simpler, and available to all.

So through most of my first year I asked myself “Where is the present-day Bauhaus?” I was certain to find the contemporary equivalent and join in. My personal drive isn’t to live forever, rather my goal is to create something that will. After searching for months, I couldn’t find any new history-changing movements in architecture or art in general. One day in my second year, I discovered free software through a friend who showed me how valuable a tool Linux can be. Being a computer enthusiast, I knew the term, but not the philosophy behind it; once I learned about it everything clicked: I’d found what I was searching for. The next year of my academic life I started studying Computer Engineering, and the rest… well, simply fell into place.

A few times every century a social changing movement arises; right now, the free software movement and the emergence of open source software in mainstream business and culture is defining our tools and rights in a world rapidly switching from analog to digital. Much like how new ideas introduced during the Bauhaus movement changed the architecture and design industries, open source software and the free software movement are changing how we develop modern technology; I feel very proud and lucky to be a small part of it.

Samsung’s Process for Kicking Off a New Open Source Project

Consistency is everything.

If launching open source projects is part of your job, it is incredibly helpful to have a clear, consistent, and repeatable process for open sourcing code and building a project.

Why? There are a few reasons. For one, it increases your odds of success if you can identify the parts of the process that worked well before, and repeat them. Project launches are about people as much as technology. There are actions that attract others, and actions that drive others away; it’s beneficial to remember which is which. If you can’t convince others to join and use your project, you may as well just post the code and be done with it.

Another major reason is time. I seriously doubt I’m alone in observing that the typical “We’re launching an OSS project next month! Um, where do we start?” emails usually come with little warning. Most of the time another group has been working on it for a while, and we get a heads up when they think they’re done and ready to go.

But more often than not, they’re about halfway there – and their original deadlines are still in place. Having a structured process can help quickly identify what’s already done, what still needs to be done, and whether that launch date is actually realistic.

The Samsung Open Source Group maintains these processes for a variety of project types, customized based upon our own experience in launching projects as well as the specific needs of our company. Here’s a high level overview of one we use when preparing to launch a major standalone open source project.


We start by asking some basic questions. One of the most important steps in this process is determining, right at the start, if it’s even worth doing as a standalone OSS project. If, for example, the project addresses a niche that only you can reasonably contribute to, it may be faster and cheaper to publish the source code under an appropriate license without constructing a full project.

Once you’re past that first sanity check, you should be sure there’s a genuine reason for others to contribute and use the code. This will help determine the ideal project governance structure, which in turn will help you predict where you’ll need to focus your time and energy.

Once you have identified the “to-be” state, you need to ask one of the hardest questions in the entire process: “Do we have the willpower, skills, and funding to see this through until it becomes self-sustaining? What will we do if (for reasons beyond our control) it never becomes self-sustaining?”

Another deceptively simple but guaranteed-to-cause-you-pain-if-you-overlook-it question is, “How do we define and measure success so that we can justify our budget every 12 months?” If you work in a large corporate environment, you know exactly what I’m talking about. The definition of success will change immensely in the first few years of a project, so make sure your plans reflect this.

We also ask how this project will affect Samsung’s reputation. Are we going to win new advocates? Create new competitors? Fundamentally alter the economics of an ecosystem? These are all things that must be considered.


If you are launching a standalone open source project you will need to determine the structure of the Board of Directors (for members to make decisions about money and policy), a Technical Steering Committee (for contributors to self-govern the development and release process), and other specialized committees like Marketing or Certification.

Next, we ask who is expected to participate in each governing body, and how. In some cases, you can look into the governance practices of similar communities, particularly if membership could overlap. This can give you a reasonable idea of what level of participation can be expected from others, what dues should be charged, and the membership benefits you should offer.

This is also the right time to draft code submission requirements, processes by which committers, reviewers, and maintainers are selected, and so forth.


Of course, I’m not going to give you any legal advice. However, there are some questions you should ask your own attorneys.

For example, what is the project’s policy on the Developer Certificate of Origin? Should we use a CLA? Who will actually produce the project’s legal documents, such as membership agreements, bylaws, and IPR/license policy?

This is also a good time to investigate similar communities, as well as vertical components in the stack, and determine if they will influence the project’s policies. In an ideal situation, you want to match them as closely as possible. This reduces potential sources of friction when existing developers and users start participating in your project.

Project Budget

This is hard to predict in advance, particularly if you don’t already have a roster of committed companies. I have found it best to create three budgets: the absolute minimum to keep the lights on, the ideal case, and the blowout success case. This is tightly tied to the willpower question above. If only a few others join, who will make up the funding gaps? If membership revenue doesn’t ramp up as expected, will others help fund the difference?


Speaking of hard-to-predict, membership is one of the other big unknowns. Sure, you can come up with plenty of reasons others should want to join, but will they actually do it?

There are ways to improve your odds. One of the most effective strategies is to use your own business development people to approach current business partners. They already have a relationship with you, and probably also see the same benefits from participating in the project. This is an advantage, particularly if your business development teams can approach people who can make a meaningful decision about committing to membership.

At any rate, it is important to come up with a list of companies, to know who can reach them, and to do this before the launch.


In many respects, launching a project is similar to launching a new product. You need to build a brand, and we have a few key items we look for in this process. Digital assets such as logos and presentation templates need to be created, as do style guides. Events need to be planned, both your own as well as some that are organized outside your team.

One thing that can get overlooked is registering your project’s social media handles, even if you don’t plan to use them immediately.  Transferring ownership can be difficult after the fact.

Finally, it’s important that there be a distinction between developer and end user outreach. The two audiences may overlap, but rarely are they exactly the same. As such, there will be different messages, delivered at different times.


Compliance and certification requirements are often tied to the rights to use a project’s trademark. In some cases, it can also be tied to the project’s IPR policy. Our process asks relevant questions such as, “Will there be a defined spec, or will it be derived from the code?” “Do you need to plan for plugfests and test labs, or will everyone use the same implementation?”


Finally, this checklist ends with infrastructure. This is one topic that can often lead to bikeshedding, simply because everyone has a favorite bug tracker/build system/wiki/whatever and it’s an easy problem to tackle. However, the key question is not “What do you like to use,” but rather, “What will help the project succeed?”

The preceding questions should give insight whether there are other external factors that would influence your infrastructure decisions. For example, if your industry builds their stacks with Yocto, you know what you should use (if you want your project to be adopted).

Wrapping up

Of course, there’s a lot more depth than what I wrote here. We’ve developed a 2+ day workshop that walks internal Samsung teams through all of their decisions, as launching a new project is not a decision to be taken lightly. However, once you’ve done it a few times and taken note of what works and what doesn’t, it becomes considerably easier.

10 Steps to Improve Your Company’s Success in Open Source

Open source communities can be vast, have an extremely fast rate of development, and have numerous companies and individuals who influence the project’s direction. Because of this diversity and speed it can be very easy for a company’s contributions to be lost in the shuffle, and it’s vital for any company that wants to contribute significant code upstream to establish themselves within the community.

We’ve worked hard to establish a strong open source engineering team here at Samsung, and we’ve learned a lot about what it takes to be successful at this along the way. Without further ado, here are 10 tips to help you improve your company’s success at contributing code to the an open source community.

  1. Hire key developers and maintainers from the community. This is a critical step that allows you to gain skills and expertise. Two or three people from any given project are enough to make a serious impact.
  2. Setup a mentorship program where senior and more experienced developers provide guidance to junior and less experienced developers. Typically, the mentorship program runs for 3 to 6 months. The mentor will supervise the work of the mentee, assign tasks, and ensure proper results. The mentor should review code the mentee produces and provide feedback before it’s proposed to the open source community.
  3. Create an open source developer track in your HR system. This provides open source developers inside your company with a good sense of how their career will progress. Performance-based bonuses need to be adjusted for a different set of goals specifically tailored to open source developers.
  4. Develop and offer internal training to open source developers. Training should involve three primary components:
    1. Technical training for specific subsystems and domains. Typically, maintainers or senior developers will provide this training.
    2. Open source development methodology course that teach junior staff how open source development works and how to best engage the community.
    3. Open source compliance course that teaches staff the basics of compliance principles and open source licenses. This should also inform them of the company’s policy and process.
  5. Participate in community events. Send your developers to community events and support them in presenting their work. Conferences, meetups, summits, and hackathons are all valuable events that help your developers get more deeply involved in the community’s development efforts.
  6. Provide proper, hassle-free IT infrastructure that will allow your developers to communicate with and participate in the open source community. For example, access to IRC servers is key so staff can have live communications with other developers from the community.
  7. Join vital open source foundations. These provides access to beneficial open source resources, services, events, and leadership.
  8. Create an internal system to track developer contributions and impact. Tools like GrimoireLab and gitdm can be used to extract valuable information from the source code such as what individuals are contributing the most code and what companies are influencing the codebase. Examples of items to track (per developer):
    1. Number of patches submitted
    2. Acceptance rate (Patches submitted / Patches accepted)
    3. Type of patch (new feature, enhancing existing functionality, bug fix, documentation, other)
    4. Time taken to merge code upstream
  9. Contribute to areas that are useful to more than one business unit. This will provide more value to the company and provide an ROI to more than one business unit, increasing your chances of getting more funding and support.
  10. Create collaboration projects with other business units related to the open source project. Initially, the open source engineering team can deliver training to the developers working for the business units, and then follow up with workshops. The goal is to understand the pain points and challenges business units have with the project so the open source engineering team can support and solve these issues. Creating this collaboration is very critical to understanding business needs so the open source team can be more effective at fulfilling them.

These 10 steps should go a long way towards improving your success within any open source community. If there is anything you think we’ve missed, please share it in the comments!