compliance

There are generally two teams involved in achieving open source license compliance within an organization: a core team and an extended team of individuals from various departments.

No individual, no matter how adept, can successfully implement open source compliance across an entire organization. Keeping track of where and how open source code is used, approved, and shipped must be a cross-functional team effort.

From core engineering and product teams, to legal counsel and upper management, compliance involves individuals in many roles from various departments throughout the company.

In this article, highlighting a chapter of The Linux Foundation ebook Open Source Compliance in the Enterprise by Ibrahim Haddad, we’ll give an overview of the roles and responsibilities that any open source compliance program should include. Together, these are the individuals who will make sure your company stays current and compliant with the open source licenses in the code you use and ship.

3 Key roles on an open source compliance team

There are generally two teams involved in achieving compliance: a core team and an extended team, with the latter typically being a superset of the former. The core team, often called the Open Source Review Board (OSRB), consists of three key representatives from engineering and product teams, one or more legal counsels, and the compliance officer/ open source program office manager.

Legal representative: A legal counsel or paralegal, depending on the task. Reviews and approves usage, modification, and distribution of free and open source software (FOSS); provides guidance on licensing; contributes to compliance training; reviews and approves open source notices; and more.

Engineering and product team representative: Follows compliance policies and processes; requests approval to use (and/or contribute) to open source projects; responds quickly to all questions; conducts design, architecture, and code reviews; prepares software packages for distribution; and more.

Open source compliance officer, manager, or director: Not necessarily a dedicated resource, this person drives all compliance activities; coordinates source code scans and audits and distribution of source code package; contributes to compliance training and creation of new tools to facilitate automation and FOSS discovery in a dev environment; and more.

Others involved in open source compliance

The extended team includes a larger group of individuals from across multiple departments who contribute on an on-going basis to the open source compliance efforts. However, unlike the core team (in substantial organizations), members of the extended team are working on compliance only on a part- time basis, based on tasks they receive from the core review board. Roles and responsibilities include:

  • Documentation – Includes open source license information and notices in the product documentation including license text, written offer, copyrights and attribution notices
  • Supply Chain – Mandates third-party software providers to disclose open source in licensed or purchased software components and assists with ingress of third-party software bundled with and/or including open source software
  • Corporate Development – Requests open source compliance be completed before a merger or acquisition, or when receiving source code from outsourced development centers or third-party software vendors.
  • IT – Provides support and maintenance for the tools and automation infrastructure used by the compliance program and creates and/or acquires new tools based on OSRB requests
  • Localization – Translates basic information in target languages about open source information related to the product or software stack
  • Open Source Executive Committee (OSEC) – Typically includes executives representing Engineering and Legal. The OSEC reviews and approves proposals to release IP and proprietary source code under an open source license.

Read other articles in this series:

The 7 Elements of an Open Source Management Program: Strategy and Process

The 7 Elements of an Open Source Management Program: Teams and Tools

How and Why to do Open Source Compliance Training at Your Company

Basic Rules to Streamline Open Source Compliance For Software Development

How to Raise Awareness of Your Company’s Open Source License Compliance

Establishing a Clean Software Baseline for Open Source License Compliance

Ibrahim Haddad (Ph.D.) is Vice President of R&D and the Head of the Open Source Group at Samsung Research America. He is responsible for overseeing Samsung’s open source strategy and execution, internal and external R&D collaborations, supporting M&A and Corporate VC activities, and representing Samsung towards open source foundations. He is currently serving as Vice President of the Open Connectivity Foundation and the Director on the Board representing Samsung Electronics.

 

dock rising out of the water

Salesforce says one key to open source program success is to focus on good “on ramps” to your open source projects with great set up documentation and healthy forums.

Salesforce learned early on that open source projects stay healthy when they have a diverse community of stakeholders that have an interest in making the software succeed.

Apache Phoenix started at Salesforce as its own open source Phoenix project. But it didn’t find success until people from outside Salesforce also got invested and the project no longer depended on the needs and desires of one company. In a true community effort, people from other companies joined in and said, ‘this is useful for us and we want to contribute,’” says Ian Varley, a Software Architect at Salesforce who recently led the open source program there. In the end, this diverse community is what allowed it to become an Apache project and incorporate new features that the company’s own engineers could never have dreamed up.

Salesforce stays focused on this concept of cultivating diverse interests to use and participate in its projects. At the same time, it’s equally focused on aligning its internal stakeholders — from engineering to legal, marketing and PR — with its open source efforts.

Open source program goals at Salesforce

Salesforce has many priorities around open source. The company’s open source strategy keeps everyone aligned. The dedicated open source program team circulates internal documents to the company’s engineering team that provide strategic guidance and encourage the creation and use of open source. The documents provide the foundation for an open source culture and let the team know in no uncertain terms that the company’s leaders are fully behind the strategy.

Open source is increasingly a part of just about every software project in every company that’s out there. It stands to reason that every possible type of business model you can have with open source is going to come into being and try its hand in the market.

Salesforce is a Software-as-a-service vendor, and doesn’t release the end customer-facing products that it sells as open source. Instead, the engineering team focuses on open sourcing shared infrastructure components, libraries, and tools that other companies might find generally useful, as well as samples, and SDKs that are of benefit to their customers.

How Salesforce measures open source success

One goal of the company’s open source program is building its reputation among developers. Engineers who may not use Salesforce products will sometimes look at the company’s open source projects and say, “Hey, this company is really involved with some great stuff,” Varley said.

“Open source is a window for (external developers) to see the great engineering that’s going on inside of the company that they otherwise wouldn’t be able to. – Ian Varley, Software Architect at Salesforce.

The open source program also focuses on expanding the communities that align behind the company’s own open source projects. The communities don’t just use their software, they also contribute to it. So they focus on creating “on ramps” to their projects such as a clear approval process for patches, improved documentation, healthy forums, and welcoming and responsive maintainers.  

“We’ve succeeded when we have given people ways to get involved with our projects that don’t require them to have a PhD or to have been working in a similar area for 25 years. You need ways for them to get involved quickly,” Varley says.

Salesforce also measures its own success against the industry-wide success of open source. The more progress there is in open source, in all of its many dimensions, the better off everyone is because more open source means more progress in the industry as a whole. If Salesforce can raise the baseline of what is commodity software and what constitutes shared components that everybody can depend on,  the whole industry benefits.

Example: Apache Phoenix

Apache Phoenix is an open source big data analytics platform that’s now part of the Apache Software Foundation. But when Phoenix started, it was just a project a couple of Salesforce engineers built for some specific internal use cases. But, before long, the small team realized that anybody could benefit from the project and its velocity would improve if the whole world was working on it. So he made the pitch to open source it and turn it into a community project.

Within the first year of creating the open source Phoenix project, the Salesforce engineers started getting significant contributions in functionality from two or three big companies that had found Phoenix and wanted to join the project. By opening the project up to outside use and contribution, the Phoenix project progressed far beyond what the original engineers would have been able to do on their own.

5 Key lessons for open source program managers

Looking back at his 4 years of experience managing open source at Salesforce, Varley has five key lessons for companies that may just be getting started with their own open source programs:

  • Create a company-wide policy that strongly encourages the use and creation of open source internally.
  • Recognize that a community can advance a project far beyond what can be achieved internally.
  • Seek input on your open source program from many different types of stakeholders. Engineers should not be the only stakeholders—your legal team and executive management should also be directly involved, for example.
  • Focus on good “on ramps” to your open source projects with great set up documentation and healthy forums.
  • Recognize that open source success can drive industry-wide success and better products everywhere.

This article was produced in partnership with the TODO (Talk Openly Develop Openly) Group as part of the Open Source Guides for the Enterprise

 

dock rising out of the water

Salesforce says one key to open source program success is to focus on good “on ramps” to your open source projects with great set up documentation and healthy forums.

Salesforce learned early on that open source projects stay healthy when they have a diverse community of stakeholders that have an interest in making the software succeed.

Apache Phoenix started at Salesforce as its own open source Phoenix project. But it didn’t find success until people from outside Salesforce also got invested and the project no longer depended on the needs and desires of one company. In a true community effort, people from other companies joined in and said, ‘this is useful for us and we want to contribute,’” says Ian Varley, a Software Architect at Salesforce who recently led the open source program there. In the end, this diverse community is what allowed it to become an Apache project and incorporate new features that the company’s own engineers could never have dreamed up.

Salesforce stays focused on this concept of cultivating diverse interests to use and participate in its projects. At the same time, it’s equally focused on aligning its internal stakeholders — from engineering to legal, marketing and PR — with its open source efforts.

Open source program goals at Salesforce

Salesforce has many priorities around open source. The company’s open source strategy keeps everyone aligned. The dedicated open source program team circulates internal documents to the company’s engineering team that provide strategic guidance and encourage the creation and use of open source. The documents provide the foundation for an open source culture and let the team know in no uncertain terms that the company’s leaders are fully behind the strategy.

Open source is increasingly a part of just about every software project in every company that’s out there. It stands to reason that every possible type of business model you can have with open source is going to come into being and try its hand in the market.

Salesforce is a Software-as-a-service vendor, and doesn’t release the end customer-facing products that it sells as open source. Instead, the engineering team focuses on open sourcing shared infrastructure components, libraries, and tools that other companies might find generally useful, as well as samples, and SDKs that are of benefit to their customers.

How Salesforce measures open source success

One goal of the company’s open source program is building its reputation among developers. Engineers who may not use Salesforce products will sometimes look at the company’s open source projects and say, “Hey, this company is really involved with some great stuff,” Varley said.

“Open source is a window for (external developers) to see the great engineering that’s going on inside of the company that they otherwise wouldn’t be able to. – Ian Varley, Software Architect at Salesforce.

The open source program also focuses on expanding the communities that align behind the company’s own open source projects. The communities don’t just use their software, they also contribute to it. So they focus on creating “on ramps” to their projects such as a clear approval process for patches, improved documentation, healthy forums, and welcoming and responsive maintainers.  

“We’ve succeeded when we have given people ways to get involved with our projects that don’t require them to have a PhD or to have been working in a similar area for 25 years. You need ways for them to get involved quickly,” Varley says.

Salesforce also measures its own success against the industry-wide success of open source. The more progress there is in open source, in all of its many dimensions, the better off everyone is because more open source means more progress in the industry as a whole. If Salesforce can raise the baseline of what is commodity software and what constitutes shared components that everybody can depend on,  the whole industry benefits.

Example: Apache Phoenix

Apache Phoenix is an open source big data analytics platform that’s now part of the Apache Software Foundation. But when Phoenix started, it was just a project a couple of Salesforce engineers built for some specific internal use cases. But, before long, the small team realized that anybody could benefit from the project and its velocity would improve if the whole world was working on it. So he made the pitch to open source it and turn it into a community project.

Within the first year of creating the open source Phoenix project, the Salesforce engineers started getting significant contributions in functionality from two or three big companies that had found Phoenix and wanted to join the project. By opening the project up to outside use and contribution, the Phoenix project progressed far beyond what the original engineers would have been able to do on their own.

5 Key lessons for open source program managers

Looking back at his 4 years of experience managing open source at Salesforce, Varley has five key lessons for companies that may just be getting started with their own open source programs:

  • Create a company-wide policy that strongly encourages the use and creation of open source internally.
  • Recognize that a community can advance a project far beyond what can be achieved internally.
  • Seek input on your open source program from many different types of stakeholders. Engineers should not be the only stakeholders—your legal team and executive management should also be directly involved, for example.
  • Focus on good “on ramps” to your open source projects with great set up documentation and healthy forums.
  • Recognize that open source success can drive industry-wide success and better products everywhere.

This article was produced in partnership with the TODO (Talk Openly Develop Openly) Group as part of the Open Source Guides for the Enterprise

ComcastComcast’s involvement in open source was a gradual process that evolved over time. The company eventually created two open source program offices, one for the NBC business and another for the cable side of the business, which is the subject of this profile.

Comcast began contributing to open source around 2006 when Jon Moore, Chief Software Architect, made a patch contribution to Apache HTTP. He showed the management team that it was more cost effective to have the patch incorporated into the main project than it was to maintain it separately.

Working with an interdisciplinary team, Moore worked to set up an open source advisory council, which consisted of legal and technical subject matter experts. They reviewed contributions and created internal guidelines focused on good open source practices and community building. In 2013, when they started tracking these contributions, they had 13. This year, they plan to do almost 10x that.

“When companies establish open source practices they send a big message saying that we’re serious about open source and that we want to invest in it,” said Nithya Ruff, Senior Director of the Open Source Practice at Comcast (@nithyaruff).

Six C’s of Open Source Program Practice

In 2016, Comcast hired Ruff to lead an increasingly vital open source strategy. The practice has support from the highest levels of the Comcast leadership team who wanted an organization that would field questions, educate employees, and create awareness.

The open source program practice currently has three full-time people while relying on functional experts in legal, engineering, IT, PR, and more to help scale the programs. The goal is to coach, guide, advise, recommend, and serve as a consultant to employees. Ruff summarizes the function of an open source practice with “the six C’s”: consumption, contribution, compliance, communication, collaboration, and competency-building.

The open source practice has two main goals.

  1. Make it easier for people inside the company to work in open source. Whether it’s consumption of open source, contribution to open source, or collaboration with communities, foundations, and organizations, the goal is to remove legal, process, tool, communication, and awareness barriers.
  2. Be visible externally in open source and technology communities. Many people don’t know that Comcast is a technology company with thousands of developers so they want to raise awareness and share what they’re doing.

Open source contributions

Comcast has open sourced a few projects in addition to contributing significantly to existing open source communities, like OpenStack. Apache Traffic Control was started within Comcast and has been contributed to the Apache Software Foundation where it is currently in incubation.

They were also instrumental in setting up an independent consortium called the RDK Management Project focused on creating a standard around set-top boxes. The RDK software uses the Yocto build system to create a consistent layer such that everyone from the semiconductor vendors right up the chain to OEMs and ISVs can use a consistent system and structure to build the content for set-top boxes and similar devices.

Comcast open sourced its Speed-TestJS tool, which is a test of internet speed, because the company wanted to be transparent to the world in terms of how they measure speed. The project also allows people to use the tool themselves to make sure that they felt that Comcast was delivering what it promised. This is a great example of a tool that could create more trust as a result of being open.

In addition to contributing to projects, Comcast is also a member of a number of foundations, including Cloud Foundry Foundation, the Apache Software FoundationThe Linux FoundationYocto ProjectLinaroOpenStack FoundationOpen Network Automation Platform (ONAP), and OpenDaylight.

Comcast's open source collaborationsThrough these contributions, Comcast has benefited from the goodwill that comes from participating in open source communities. Comcast’s contributions have also helped the company recruit new developers. Developers today want to work for companies that are good open source citizens, and Comcast’s contributions in a variety of communities demonstrate that they are serious about their commitment to open source.

Aligning with the Business

“The establishment of the practice, visible engagement at the foundation level, increased contributions, leadership support, and tooling support as a company have made it easy to do open source,” Ruff said.

It’s important to make sure that your company’s open source strategies are closely aligned with its business strategy. The open source office should really understand the goals of the company and enable them in the open source strategy. This strategic alignment allows the open source practice to remain aligned with the broader company goals at Comcast to encourage long-term success for the practice and the company as a whole.

This article was produced in partnership with the TODO (Talk Openly Develop Openly) Group as part of the Open Source Guides for the Enterprise

ComcastComcast’s involvement in open source was a gradual process that evolved over time. The company eventually created two open source program offices, one for the NBC business and another for the cable side of the business, which is the subject of this profile.

Comcast began contributing to open source around 2006 when Jon Moore, Chief Software Architect, made a patch contribution to Apache HTTP. He showed the management team that it was more cost effective to have the patch incorporated into the main project than it was to maintain it separately.

Working with an interdisciplinary team, Moore worked to set up an open source advisory council, which consisted of legal and technical subject matter experts. They reviewed contributions and created internal guidelines focused on good open source practices and community building. In 2013, when they started tracking these contributions, they had 13. This year, they plan to do almost 10x that.

“When companies establish open source practices they send a big message saying that we’re serious about open source and that we want to invest in it,” said Nithya Ruff, Senior Director of the Open Source Practice at Comcast (@nithyaruff).

Six C’s of Open Source Program Practice

In 2016, Comcast hired Ruff to lead an increasingly vital open source strategy. The practice has support from the highest levels of the Comcast leadership team who wanted an organization that would field questions, educate employees, and create awareness.

The open source program practice currently has three full-time people while relying on functional experts in legal, engineering, IT, PR, and more to help scale the programs. The goal is to coach, guide, advise, recommend, and serve as a consultant to employees. Ruff summarizes the function of an open source practice with “the six C’s”: consumption, contribution, compliance, communication, collaboration, and competency-building.

The open source practice has two main goals.

  1. Make it easier for people inside the company to work in open source. Whether it’s consumption of open source, contribution to open source, or collaboration with communities, foundations, and organizations, the goal is to remove legal, process, tool, communication, and awareness barriers.
  2. Be visible externally in open source and technology communities. Many people don’t know that Comcast is a technology company with thousands of developers so they want to raise awareness and share what they’re doing.

Open source contributions

Comcast has open sourced a few projects in addition to contributing significantly to existing open source communities, like OpenStack. Apache Traffic Control was started within Comcast and has been contributed to the Apache Software Foundation where it is currently in incubation.

They were also instrumental in setting up an independent consortium called the RDK Management Project focused on creating a standard around set-top boxes. The RDK software uses the Yocto build system to create a consistent layer such that everyone from the semiconductor vendors right up the chain to OEMs and ISVs can use a consistent system and structure to build the content for set-top boxes and similar devices.

Comcast open sourced its Speed-TestJS tool, which is a test of internet speed, because the company wanted to be transparent to the world in terms of how they measure speed. The project also allows people to use the tool themselves to make sure that they felt that Comcast was delivering what it promised. This is a great example of a tool that could create more trust as a result of being open.

In addition to contributing to projects, Comcast is also a member of a number of foundations, including Cloud Foundry Foundation, the Apache Software FoundationThe Linux FoundationYocto ProjectLinaroOpenStack FoundationOpen Network Automation Platform (ONAP), and OpenDaylight.

Comcast's open source collaborationsThrough these contributions, Comcast has benefited from the goodwill that comes from participating in open source communities. Comcast’s contributions have also helped the company recruit new developers. Developers today want to work for companies that are good open source citizens, and Comcast’s contributions in a variety of communities demonstrate that they are serious about their commitment to open source.

Aligning with the Business

“The establishment of the practice, visible engagement at the foundation level, increased contributions, leadership support, and tooling support as a company have made it easy to do open source,” Ruff said.

It’s important to make sure that your company’s open source strategies are closely aligned with its business strategy. The open source office should really understand the goals of the company and enable them in the open source strategy. This strategic alignment allows the open source practice to remain aligned with the broader company goals at Comcast to encourage long-term success for the practice and the company as a whole.

This article was produced in partnership with the TODO (Talk Openly Develop Openly) Group as part of the Open Source Guides for the Enterprise

open source guides

Last March we held a TODO Group track at Open Source Leadership Summit focused entirely on sharing best practices for businesses managing and building out open source programs. More than a dozen open source program leads and other leaders from companies shared their tips and best practices at the event.

Furthermore in the last year or so, we have seen companies like AWS build out an open source program via @AWSOpen and even companies like VMWare hired their first Chief Open Source Officer. We’ve had many organizations approach TODO Group members asking for advice on how to get started with an open source program.

To help companies inform and improve their open source practices, we here at the TODO Group have ramped up our knowledge sharing this year and are offering more free resources by open sourcing a set of living open source guides for the enterprise to help you learn more about setting up an open source program. Topics include:

How to Create an Open Source Program
Measuring Your Open Source Program
Tools for Measuring Your Open Source Program
Using Open Source Code
Participating in Open Source Communities
Recruiting Open Source Developers

We are also profiling the open source programs and many of these companies, which have shared their tips and best practices. Their advice comes from years of professional open source program management experience at some of the largest and most successful software companies – many which built their businesses on open source software and contribute significantly to open source communities. We have open source two case studies initially and plan to do more soon:

These guides and case studies are open source on GitHub under a CC-BY-SA 4.0 license. If you would like us to feature your open source program in our profiles please submit a pull request at https://github.com/todogroup/guides. We also welcome your contributions and ideas to these guides and invite you to contribute content to the existing versions, create case studies or new guides.

If you’re interested in starting an open source program or collaborating with your peers in open source program management, please consider joining the TODO Group!

open source guides

Last March we held a TODO Group track at Open Source Leadership Summit focused entirely on sharing best practices for businesses managing and building out open source programs. More than a dozen open source program leads and other leaders from companies shared their tips and best practices at the event.

Furthermore in the last year or so, we have seen companies like AWS build out an open source program via @AWSOpen and even companies like VMWare hired their first Chief Open Source Officer. We’ve had many organizations approach TODO Group members asking for advice on how to get started with an open source program.

To help companies inform and improve their open source practices, we here at the TODO Group have ramped up our knowledge sharing this year and are offering more free resources by open sourcing a set of living open source guides for the enterprise to help you learn more about setting up an open source program. Topics include:

How to Create an Open Source Program
Measuring Your Open Source Program
Tools for Measuring Your Open Source Program
Using Open Source Code
Participating in Open Source Communities
Recruiting Open Source Developers

We are also profiling the open source programs and many of these companies, which have shared their tips and best practices. Their advice comes from years of professional open source program management experience at some of the largest and most successful software companies – many which built their businesses on open source software and contribute significantly to open source communities. We have open source two case studies initially and plan to do more soon:

These guides and case studies are open source on GitHub under a CC-BY-SA 4.0 license. If you would like us to feature your open source program in our profiles please submit a pull request at https://github.com/todogroup/guides. We also welcome your contributions and ideas to these guides and invite you to contribute content to the existing versions, create case studies or new guides.

If you’re interested in starting an open source program or collaborating with your peers in open source program management, please consider joining the TODO Group!

[vc_row type=”in_container” full_screen_row_position=”middle” scene_position=”center” text_color=”dark” text_align=”left” overlay_strength=”0.3″][vc_column column_padding=”no-extra-padding” column_padding_position=”all” background_color_opacity=”1″ background_hover_color_opacity=”1″ column_shadow=”none” width=”1/1″ tablet_text_alignment=”default” phone_text_alignment=”default” column_border_width=”none” column_border_style=”solid”][image_with_animation image_url=”20506″ alignment=”center” animation=”None” box_shadow=”none” max_width=”100%”][/vc_column][/vc_row][vc_row type=”in_container” full_screen_row_position=”middle” scene_position=”center” text_color=”dark” text_align=”left” overlay_strength=”0.3″][vc_column column_padding=”no-extra-padding” column_padding_position=”all” background_color_opacity=”1″ background_hover_color_opacity=”1″ column_shadow=”none” width=”1/1″ tablet_text_alignment=”default” phone_text_alignment=”default” column_border_width=”none” column_border_style=”solid”][vc_column_text]Community — what a profound difference it can make for projects, businesses and organizations of all types. I’ve spent my entire career helping organizations build communities, ranging from internal communities to developer communities, with a strong focus on open source communities. The goal in fostering a healthy community around open source is to engage consumers, customers, and others and encourage them to contribute. With these thoughts in mind, let us consider a few of the important first steps in setting a community strategy, and then I want to tell you about a very special community-focused event that is coming up.

First Steps to Building Open Source Communities

What should a company do when setting an open source community strategy? This is less well understood than it should be. First, it is critical to understand the business value that can be derived from building a community. Just as diversity within an organization can drive tangibly better business results, a healthy community can too.

When taking a stab at developing a community, many people are inclined to rush into blogs and social media strategies without defining the precise business value that a healthy community can drive. Once you understand how to drive toward business value, you can then put together a strategy as a broad set of goals and actions. These are “big rocks” that you pledge to execute on for, say, a year.

Among the big rocks, you want to define the the stakeholders surrounding your community. Are engineers represented as well as leaders from diverse functions throughout your organization? In addition, you want to carefully plan out your governance structure, and codify it so that everyone has a central reference point — typically a strategy document — to refer to.

So, in summary, the first few steps toward building a healthy open source community are:

  • Understand the business value
  • Define the stakeholders
  • Set a strategy
  • Execute
  • Where required, codify a governance structure

There is much more to do, of course, in setting your healthy community on a good path. Should you hire a community manager? What will your social media strategy be?

A Conference on Open Source Communities

With all this in mind, if you would like to learn much more about building out an open source community strategy that can flourish, I am chairing a special event coming up and it would be great to see you there. At The Linux Foundation’s upcoming Open Source Summit North America , taking place in Los Angeles Sept. 11-14, 2017, I am the founder and program chair of the Open Community Conference. I have been working with The Linux Foundation to make this a very compelling conference. The theme of the overall summit is “inspiration everywhere,” and there will be a collection of very inspiring open source experts at the Open Community Conference.

One of the other regular conferences that I lead is the Community Leadership Summit, but the Open Community Conference will differ in format from that one.

The Community Leadership Summit brings together community managers and leaders to discuss, debate, and evolve community strategy (and how the sausage is made).

By contrast, the Open Community Conference features a very rich and highly accessible set of presentations designed to let everyone — including people new to open source — learn about how to build rich communities around open source, harness these approaches, and thereby drive business value.

Here are just a few of the top-notch presentations and presenters that we have lined up for Open Community Summit:

Aim to Be an Open Source Zero – Guy Martin, Autodesk

Open Source Project Infrastructures – Elizabeth K. Joseph, Mesosphere

Scaling Open Source: Lessons Learned at the Apache Software Foundation – Phil Steitz, Apache

So You’ve Decided You Need an Open Source Program Office – Duane O’Brien, PayPal & Nithya Ruff, Comcast

Bootstrapping Community – Colin Charles, Percona

Open Source Licensing 101 – Jim Jagielski, Capital One

You can learn much more about what we have planned for the Open Community Conference in a free webinar I did with The Linux Foundation, which also lays out more of the specific presentations that are scheduled. The webinar includes a Q&A session in which I address the first steps that organizations can take in setting a community strategy. I really hope to see you at the conference, and you can follow my updates on Twitter @jonobacon.[/vc_column_text][/vc_column][/vc_row]

[vc_row type=”in_container” full_screen_row_position=”middle” scene_position=”center” text_color=”dark” text_align=”left” overlay_strength=”0.3″][vc_column column_padding=”no-extra-padding” column_padding_position=”all” background_color_opacity=”1″ background_hover_color_opacity=”1″ column_shadow=”none” width=”1/1″ tablet_text_alignment=”default” phone_text_alignment=”default” column_border_width=”none” column_border_style=”solid”][image_with_animation image_url=”20506″ alignment=”center” animation=”None” box_shadow=”none” max_width=”100%”][/vc_column][/vc_row][vc_row type=”in_container” full_screen_row_position=”middle” scene_position=”center” text_color=”dark” text_align=”left” overlay_strength=”0.3″][vc_column column_padding=”no-extra-padding” column_padding_position=”all” background_color_opacity=”1″ background_hover_color_opacity=”1″ column_shadow=”none” width=”1/1″ tablet_text_alignment=”default” phone_text_alignment=”default” column_border_width=”none” column_border_style=”solid”][vc_column_text]Community — what a profound difference it can make for projects, businesses and organizations of all types. I’ve spent my entire career helping organizations build communities, ranging from internal communities to developer communities, with a strong focus on open source communities. The goal in fostering a healthy community around open source is to engage consumers, customers, and others and encourage them to contribute. With these thoughts in mind, let us consider a few of the important first steps in setting a community strategy, and then I want to tell you about a very special community-focused event that is coming up.

First Steps to Building Open Source Communities

What should a company do when setting an open source community strategy? This is less well understood than it should be. First, it is critical to understand the business value that can be derived from building a community. Just as diversity within an organization can drive tangibly better business results, a healthy community can too.

When taking a stab at developing a community, many people are inclined to rush into blogs and social media strategies without defining the precise business value that a healthy community can drive. Once you understand how to drive toward business value, you can then put together a strategy as a broad set of goals and actions. These are “big rocks” that you pledge to execute on for, say, a year.

Among the big rocks, you want to define the the stakeholders surrounding your community. Are engineers represented as well as leaders from diverse functions throughout your organization? In addition, you want to carefully plan out your governance structure, and codify it so that everyone has a central reference point — typically a strategy document — to refer to.

So, in summary, the first few steps toward building a healthy open source community are:

  • Understand the business value
  • Define the stakeholders
  • Set a strategy
  • Execute
  • Where required, codify a governance structure

There is much more to do, of course, in setting your healthy community on a good path. Should you hire a community manager? What will your social media strategy be?

A Conference on Open Source Communities

With all this in mind, if you would like to learn much more about building out an open source community strategy that can flourish, I am chairing a special event coming up and it would be great to see you there. At The Linux Foundation’s upcoming Open Source Summit North America , taking place in Los Angeles Sept. 11-14, 2017, I am the founder and program chair of the Open Community Conference. I have been working with The Linux Foundation to make this a very compelling conference. The theme of the overall summit is “inspiration everywhere,” and there will be a collection of very inspiring open source experts at the Open Community Conference.

One of the other regular conferences that I lead is the Community Leadership Summit, but the Open Community Conference will differ in format from that one.

The Community Leadership Summit brings together community managers and leaders to discuss, debate, and evolve community strategy (and how the sausage is made).

By contrast, the Open Community Conference features a very rich and highly accessible set of presentations designed to let everyone — including people new to open source — learn about how to build rich communities around open source, harness these approaches, and thereby drive business value.

Here are just a few of the top-notch presentations and presenters that we have lined up for Open Community Summit:

Aim to Be an Open Source Zero – Guy Martin, Autodesk

Open Source Project Infrastructures – Elizabeth K. Joseph, Mesosphere

Scaling Open Source: Lessons Learned at the Apache Software Foundation – Phil Steitz, Apache

So You’ve Decided You Need an Open Source Program Office – Duane O’Brien, PayPal & Nithya Ruff, Comcast

Bootstrapping Community – Colin Charles, Percona

Open Source Licensing 101 – Jim Jagielski, Capital One

You can learn much more about what we have planned for the Open Community Conference in a free webinar I did with The Linux Foundation, which also lays out more of the specific presentations that are scheduled. The webinar includes a Q&A session in which I address the first steps that organizations can take in setting a community strategy. I really hope to see you at the conference, and you can follow my updates on Twitter @jonobacon.[/vc_column_text][/vc_column][/vc_row]

The 2017 Open Source Jobs Report “Found that companies are increasingly looking for full-time hires to boost efficiency and reduce time to market.”

https://siliconangle.com/blog/2017/08/23/report-organizations-clamouring-open-source-technology-skills/