Posts

Open Source Leadership Summit

Share your knowledge, best practices, and strategies at Open Source Leadership Summit.

Open Source Leadership Summit (OSLS) is an invitation-only think tank where open source software and collaborative development thought leaders convene, discuss best practices, and learn how to manage today’s largest shared technology investments.

The Linux Foundation invites you to share your knowledge, best practices, and strategies with fellow open source leaders at OSLS.  

Tracks & Suggested Topics for Open Source Leadership Summit:

OS Program Office

  • Consuming and Contributing to Open Source
  • Driving Participation and Inclusiveness in Open Source Projects
  • Standards and Open Source
  • Managing Competing Corporate Interests while Driving Coherent Communities
  • How to Vet the Viability of OS Projects
  • Open Source + Startup Business Models
  • Project Planning and Strategy
  • Internal vs. External Developer Adoption

Best Practices in Open Source Development / Lessons Learned

  • Contribution Policies
  • Promoting Your Open Source Project
  • Open Source Best Practices
  • Open Source Program Office Case Studies and Success Stories
  • Standards and Open Source

Growing & Sustaining Project Communities / Metrics and Actions Taken

  • Collaboration Models to Address Security Issues
  • Metrics for Understanding Project Health

Automating Compliance / Gaps & Successes

  • Using Trademarks in Open Communities
  • Working with Regulators / Regulated Industries
  • Working with the Government on OS
  • How to Incorporate SPDX Identifiers in Your Project
  • Legal + Compliance
  • Licensing + Patents
  • Successfully Working Upstream & Downstream

Certifying Open Source Projects

  • Security
  • Safety
  • Export
  • Government Restrictions
  • Open Source vs. Open Governance
  • New Frontiers for Open Source in FinTech and Healthcare

Futures

  • Upcoming Trends
  • R&D via Open Source
  • Sustainability

Business Leadership

  • Cultivating Open Source Leadership
  • How to Run a Business that Relies on Open Source
  • How to be an Effective Board Member
  • How to Invest in Your Project’s Success
  • Managing Competing Corporate Interests while Driving Coherent Communities
  • Monetizing Open Source & Innovators Dilemma

View here for more details on suggested topics, and submit your proposal before the Jan. 21 deadline.

Get inspired! Watch keynotes from Open Source Leadership Summit 2017.

See all keynotes from OSLS 2017 »

This free guide can help you increase your development team’s efficacy through and with open source contributions.

Open source programs are sparking innovation at organizations of all types, and if your program is up and running, you may have arrived at the point where maximizing the impact of your development is essential to continued success. Many open source program managers are now required to demonstrate the ROI of their technology development, and example open source report cards from Facebook and Google track development milestones.

This is where the new, free Improving Your Open Source Development Impact guide can help. The aim of the guide is to help you increase your development team’s efficacy through and with open source contributions. By implementing some of the best practices laid out in the guide, you can:

  • Reduce the amount of work needed from product teams
  • Minimize the cost to maintain source code and internal software branches
  • Improve code quality
  • Produce faster development cycles
  • Produce more stable code to serve as the base for products
  • Improve company reputation in key open source communities.

Open source development requires a different approach than many organizations are accustomed to. But the work becomes easier if you have a clear plan to follow. Fortunately, a whole lot of companies and individuals have already forged a path to success in contributing to significant open source projects. They have tried and true methods for establishing a leadership role in open source communities.

This open source guide offers lessons for increasing open source development impact through specific examples. Contributing to the Linux kernel is one of the hardest challenges for open source developers. With that in mind, the guide uses this case as an example, but the lessons learned will apply to nearly any open source project you’ll work with.

“It took us years of constant discussion and negotiation to break from the traditional IT setup into a more flexible environment that supports our open source development,” said Ibrahim Haddad, Vice President of R&D and Head of the Open Source Group at Samsung Research. “We made it work for us and with enough persistence you also can make it work for your open source team.”

Common Challenges

Notably, organizations run into common problems as they try to improve the impact of their open source inventions. The figure below shows some of the challenges that dedicated open source teams face in an enterprise setting.open source guidesThe Improving Your Open Source Development Impact guide can help you navigate these and other common open source-related challenges. It covers everything from evaluating ROI to optimizing practices, and it explores how to seamlessly and safely leverage existing tools to complement your open source creations.

It is one of a new collection of free guides from The Linux Foundation and The TODO Group providing valuable insight and expertise for any organization running an open source program. The guides are available now to help you run an open source program office where open source is supported, shared, and leveraged.

Check out the all the guides, and don’t miss the previous articles in the series:

How to Create an Open Source Program

Tools for Managing Open Source Programs

Measuring Your Open Source Program’s Success

Effective Strategies for Recruiting Open Source Developers

Participating in Open Source Communities

Using Open Source Code

Launching an Open Source Project: A Free Guide

openchain

OpenChain makes open source compliance more predictable, understandable, and efficient for all participants in the software supply chain.

Communities form in open source all the time to address challenges. The majority of these communities are based around code, but others cover topics as diverse as design or governance. The OpenChain Project is a great example of the latter. What began three years ago as a conversation about reducing overlap, confusion, and wasted resources with respect to open source compliance is now poised to become an industry standard.

The idea to develop an overarching standard to describe what organizations could and should do to address open source compliance efficiently gained momentum until the formal project was born. The basic idea was simple: identify key recommended processes for effective open source management. The goal was equally clear: reduce bottlenecks and risk when using third-party code to make open source license compliance simple and consistent across the supply chain. The key was to pull things together in a manner that balanced comprehensiveness, broad applicability, and real-world usability.

Main Pillars of the Project

The OpenChain Project has three pillars supported by dedicated work teams. The OpenChain Specification defines a core set of requirements every quality compliance program must satisfy. OpenChain Conformance allows organizations to display their adherence to these requirements. The OpenChain Curriculum provides the educational foundation for open source processes and solutions, while meeting a key requirement of the OpenChain Specification. The result is that open source license compliance becomes more predictable, understandable, and efficient for all participants in the software supply chain.

Reasons to Engage

The OpenChain Project is designed to be useful and adoptable for all types of entities in the supply chain. As such, it is important to distill its value proposition for various potential partners. Our volunteer community created a list of five practical reasons to engage:

  1. OpenChain makes free and open source software (FOSS) more accessible to your developers. OpenChain provides a framework for shared, compliant use of FOSS. Conforming companies create an environment that supports use of FOSS internally and sharing of FOSS with partners.
  2. OpenChain reduces overall compliance effort, saving time and legal and engineering resources. OpenChain allows companies in a supply chain to work together toward FOSS compliance and provides a consistent standard to which all must perform. By contrast, in a typical supply chain, each member of the chain has to perform FOSS compliance for software of others in the chain, wasting time and resources in a duplication of effort.
  3. OpenChain may be adapted to your existing systems. OpenChain allows you to choose your own processes to meet its requirements. OpenChain provides resources that help you design new processes from the ground up, or you may choose to use the systems you have in place.
  4. OpenChain helps your business teams work together toward a common goal. OpenChain provides a blueprint for your legal, engineering, and business teams to work together toward FOSS compliance.
  5. OpenChain allows you to conform to a stable, community-backed specification. When you adopt OpenChain, you conform to a stable specification that is widely backed by industry and community participants. OpenChain was developed in an open, collaborative process, with contributors from a wide range of industries across Asia, Europe and North America. OpenChain is being formally adopted by a growing number of both small and larger companies.

Today, the OpenChain Project is addressing its goals and moving towards wider market adoption with the support of 14 Platinum members: Adobe, Arm, Cisco, Comcast, GitHub, Harman, Hitachi, HPE, Qualcomm, Siemens, Sony, Toyota, Western Digital, and Wind River. The project also has a broad community of volunteers helping to make open source compliance easier for a multitude of market segments. As we move into 2018, the OpenChain Project is well positioned for adoption by Tier 1, Tier 2, and Tier 3 suppliers in multiple sectors, ranging from embedded to mobile to automotive to enterprise to infrastructure.

Entities of all sizes are welcome to participate in the OpenChain Project. Everyone is welcome and encouraged to join our mailing list at:

https://lists.linuxfoundation.org/mailman/listinfo/openchain

You can also send private email to the Project Director, Shane Coughlan, at coughlan@linux.com.

Autodesk is undergoing a company-wide shift to open source and inner source. And that’s on top of the culture change that both development methods require.

Autodesk is undergoing a company-wide shift to open source and inner source. And that’s on top of the culture change that both development methods require.

Inner source means applying open source development practices and methodologies to internal projects, even if the projects are proprietary. And the culture change required to be successful can be a hard shift from a traditional corporate hierarchy to an open approach. Even though they’re connected, all three changes are distinct heavy lifts.

They began by hiring Guy Martin as Director of Open Source Strategy in the Engineering Practice at Autodesk, which was designed to transform engineering across the company. Naturally, open source would play a huge role in that effort, including spurring the use of inner source. But neither would flourish if the company culture didn’t change. And so the job title swiftly evolved to Director of Open @ADSK at the company.

“I tend to focus a lot more on the culture change and the inner source part of my role even though I’m working through a huge compliance initiative right now on the open source side,” Martin said.

The history of Autodesk’s open source transformation began shortly after the shift of all its products to cloud began, including its AutoCAD architecture software, building information modeling with its Revit products, as well as  its media and entertainment products. The company’s role in open source in entertainment is now so significant that Martin often speaks at the Academy of Motion Picture Arts and Sciences on open source. They want to hear about what  Autodesk is doing as part of a larger collection of initiatives that the Academy is working on, Martin said.

At Autodesk, the goal is to spring engineers loose from their business silos and create a fully open source, cloud-centric company.

“Your primary identity detaches from being part of the AutoCAD team or part of the Revit team, or the 3ds Max or Inventor team or any of these products,” Martin explained. “It’s now shaping you into part of the Autodesk engineering team, and not your individual silo as a product organization in the company.”

Talent acquisition is among the top business goals for Open@Autodesk, especially given the company’s intense focus on innovation as well as making all of its products work seamlessly together. It takes talent skilled in open source methodologies and thinking to help make that happen. But it also means setting up the team dynamics so collaboration is more natural and less forced.

“With company cultures and some engineering cultures, the freedom to take an unconventional route to solve a problem doesn’t exist,” Martin said. “A lot of my job is to create that freedom so that smart and motivated engineers can figure out a way to put things together in a way that maybe they wouldn’t have thought of without that freedom and that culture.”

To help create an open source culture, the right tools must be in place and, oddly enough, those tools sometimes aren’t open source. For example, Martin created a single instance of Slack rather than use IRC, because Slack was more comfortable for users in other lines of the business who were already using it. The intent was to get teams to start talking across their organizational boundaries.

Another tool Martin is working with is Bitergia Analytics to monitor and manage Autodesk’s use of GitHub Enterprise.

Martin says the three key lessons he’s learned as an open source program manager are:

  1. Stay flexible because change happens
  2. Be humble but bold
  3. Be passionate.

“I’ve been at Autodesk two years but I’m still bootstrapping some of the things around culture. We have strong contributors in some projects, while in some projects we’re consuming. I think you have to do both, especially if you’re bootstrapping a new open source effort in a company. ”

“The challenge is always balancing the needs of the product teams, who have to get a product out the door, and who (and as an engineer I can say this) will take shortcuts whenever possible. They want to know, ‘why should we be doing this for the community? All we care about is our stuff.’ And it’s getting them past that. Yes, we’re doing work that’s going to be used elsewhere, but in the end we’re going to get benefits from pulling work from other people who have done work that they knew was going to be used in the community.”

participating in open source

The Linux Foundation’s free online guide Participating in Open Source Communities can help organizations successfully navigate open source waters.

As companies in and out of the technology industry move to advance their open source programs, they are rapidly learning about the value of participating in open source communities. Organizations are using open source code to build their own commercial products and services, which drives home the strategic value of contributing back to projects.

However, diving in and participating without an understanding of projects and their communities can lead to frustration and other unfortunate outcomes. Approaching open source contributions without a strategy can tarnish a company’s reputation in the open source community and incur legal risks.

The Linux Foundation’s free online guide Participating in Open Source Communities can help organizations successfully navigate these open source waters. The detailed guide covers what it means to contribute to open source as an organization and what it means to be a good corporate citizen. It explains how open source projects are structured, how to contribute, why it’s important to devote internal developer resources to participation, as well as why it’s important to create a strategy for open source participation and management.

One of the most important first steps is to rally leadership behind your community participation strategy. “Support from leadership and acknowledgement that open source is a business critical part of your strategy is so important,” said Nithya Ruff, Senior Director, Open Source Practice at Comcast. “You should really understand the company’s objectives and how to enable them in your open source strategy.”

Building relationships is good strategy

The guide also notes that building relationships at events can make a difference, and that including community members early and often is a good strategy. “Some organizations make the mistake of developing big chunks of code in house and then dumping them into the open source project, which is almost never seen as a positive way to engage with the community,” the guide notes. “The reality is that open source projects can be complex, and what seems like an obvious change might have far reaching side effects in other parts of the project.”

Through the guide, you can also learn how to navigate issues of influence in community participation. It can be challenging for organizations to understand how influence is earned within open source projects. “Just because your organization is a big deal, doesn’t mean that you should expect to be treated like one without earning the respect of the open source community,” the guide advises.

The Participating in Open Source Communities guide can help you with these strategies and more, and it explores how to weave community focus into your open source initiatives. It is one of a new collection of free guides from The Linux Foundation and The TODO Group that provide essential information for any organization running an open source program. The guides are available now to help you run an open source program office where open source is supported, shared, and leveraged. With such an office, organizations can efficiently establish and execute on their open source strategies.

These guides were produced based on expertise from open source leaders. Check out the guides and stay tuned for our continuing coverage.

Don’t miss the previous articles in the series:

How to Create an Open Source Program

Tools for Managing Open Source Programs

Measuring Your Open Source Program’s Success

Effective Strategies for Recruiting Open Source Developers

 

Open Source Summit livestream

The Linux Foundation is pleased to offer free live video streaming of all keynote sessions at Open Source Summit and Embedded Linux Conference Europe, Oct. 23 to Oct. 25, 2017.

Join 2000 technologists and community members next week as they convene at Open Source Summit Europe and Embedded Linux Conference Europe in Prague. If you can’t be there in person, you can still take part, as The Linux Foundation is pleased to offer free live video streaming of all keynote sessions on Monday, Oct. 23 through Wednesday, Oct. 25, 2017.  So, you can watch the event keynotes presented by Google, Intel, and VMware, among others.

The livestream will begin on Monday, Oct. 23 at 9 a.m. CEST (Central European Summer Time). Sign up now! You can also follow our live event updates on Twitter with #OSSummit.

All keynotes will be broadcasted live, including talks by Keila Banks, 15-year-old Programmer, Web Designer, and Technologist with her father Philip Banks; Mitchell Hashimoto, Founder, HashiCorp Founder of HashiCorp and Creator of Vagrant, Packer, Serf, Consul, Terraform, Vault and Nomad; Jan Kizska, Senior Key Expert, Siemens AG; Dirk Hohndel, VP & Chief Open Source Officer, VMware in a Conversation with Linux and Git Creator Linus Torvalds; Michael Dolan, Vice President of Strategic Programs & The Linux Foundation; and Jono Bacon, Community/Developer Strategy Consultant and Author.

Other featured conference keynotes include:

  • Neha Narkhede — Co-Founder & CTO of Confluent will discuss Apache Kafka and the Rise of the Streaming Platform
  • Reuben Paul — 11-year-old Hacker, CyberShaolin Founder and cybersecurity ambassador will talk about how Hacking is Child’s Play
  • Arpit Joshipura — General Manager, Networking, The Linux Foundation who will discuss Open Source Networking and a Vision of Fully Automated Networks
  • Imad Sousou — Vice President and General Manager, Software & Services Group, Intel
  • Sarah Novotny — Head of Open Source Strategy for GCP, Google
  • And more

View the full schedule of keynotes.

And sign up now for the free live video stream.

Once you sign up to watch the event keynotes, you’ll be able to view the livestream on the same page. If you sign up prior to the livestream day/time, simply return to this page and you’ll be able to view.

Reuben Paul, co-founder of CyberShaolin, will speak at Open Source Summit in Prague, highlighting the importance of cybersecurity awareness for kids.

Reuben Paul is not the only kid who plays video games, but his fascination with games and computers set him on a unique journey of curiosity that led to an early interest in cybersecurity education and advocacy and the creation of CyberShaolin, an organization that helps children understand the threat of cyberattacks. Paul, who is now 11 years old, will present a keynote talk at Open Source Summit in Prague, sharing his experiences and highlighting insecurities in toys, devices, and other technologies in daily use.

Reuben Paul, co-founder of CyberShaolin

We interviewed Paul to hear the story of his journey and to discuss CyberShaolin and its mission to educate, equip, and empower kids (and their parents) with knowledge of cybersecurity dangers and defenses.  

Linux.com: When did your fascination with computers start?
Reuben Paul: My fascination with computers started with video games. I like mobile phone games as well as console video games. When I was about 5 years old (I think), I was playing the “Asphalt” racing game by Gameloft on my phone. It was a simple but fun game. I had to touch on the right side of the phone to go fast and touch the left side of the phone to slow down. I asked my dad, “How does the game know where I touch?”

He researched and found out that the phone screen was an xy coordinate system and so he told me that if the x value was greater than half the width of the phone screen, then it was a touch on the right side. Otherwise, it was a touch on the left side. To help me better understand how this worked, he gave me the equation to graph a straight line, which was y = mx + b and asked, “Can you find the y value for each x value?” After about 30 minutes, I calculated the y value for each of the x values he gave me.

“When my dad realized that I was able to learn some fundamental logics of programming, he introduced me to Scratch and I wrote my first game called “Big Fish eats Small Fish” using the x and y values of the mouse pointer in the game. Then I just kept falling in love with computers.Paul, who is now 11 years old, will present a keynote talk at Open Source Summit in Prague, sharing his experiences and highlighting insecurities in toys, devices, and other technologies in daily use.

Linux.com: What got you interested in cybersecurity?
Paul: My dad, Mano Paul, used to train his business clients on cybersecurity. Whenever he worked from his home office, I would listen to his phone conversations. By the time I was 6 years old, I knew about things like the Internet, firewalls, and the cloud. When my dad realized I had the interest and the potential for learning, he started teaching me security topics like social engineering techniques, cloning websites, man-in-the-middle attack techniques, hacking mobile apps, and more. The first time I got a meterpreter shell from a test target machine, I felt like Peter Parker who had just discovered his Spiderman abilities.

Linux.com: How and why did you start CyberShaolin?
Paul: When I was 8 years old, I gave my first talk on “InfoSec from the mouth of babes (or an 8 year old)” in DerbyCon. It was in September of 2014. After that conference, I received several invitations and before the end of 2014, I had keynoted at three other conferences.

So, when kids started hearing me speak at these different conferences, they started writing to me and asking me to teach them. I told my parents that I wanted to teach other kids, and they asked me how. I said, “Maybe I can make some videos and publish them on channels like YouTube.” They asked me if I wanted to charge for my videos, and I said “No.” I want my videos to be free and accessible to any child anywhere in the world. This is how CyberShaolin was created.

Linux.com: What’s the goal of CyberShaolin?
Paul: CyberShaolin is the non-profit organization that my parents helped me found. Its mission is to educate, equip, and empower kids (and their parents) with knowledge of cybersecurity dangers and defenses, using videos and other training material that I develop in my spare time from school, along with kung fu, gymnastics, swimming, inline hockey, piano, and drums. I have published about a dozen videos so far on the www.CyberShaolin.org website and plan to develop more. I would also like to make games and comics to support security learning.

CyberShaolin comes from two words: Cyber and Shaolin. The word cyber is of course from technology. Shaolin comes from the kung fu martial art form in which my dad and are I are both second degree black belt holders. In kung fu, we have belts to show our progress of knowledge, and you can think of CyberShaolin like digital kung fu where kids can become Cyber Black Belts, after learning and taking tests on our website.

Linux.com: How important do you think is it for children to understand cybersecurity?
Paul: We are living in a time when technology and devices are not only in our homes but also in our schools and pretty much any place you go. The world is also getting very connected with the Internet of Things, which can easily become the Internet of Threats. Children are one of the main users of these technologies and devices.  Unfortunately, these devices and apps on these devices are not very secure and can cause serious problems to children and families. For example, I recently (in May 2017) demonstrated how I could hack into a smart toy teddy bear and turn it into a remote spying device.
Children are also the next generation. If they are not aware and trained in cybersecurity, then the future (our future) will not be very good. 

Linux.com: How does the project help children?
Paul:As I mentioned before, CyberShaolin’s mission is to educate, equip, and empower kids (and their parents) with knowledge of cybersecurity dangers and defenses.

As kids are educated about cybersecurity dangers like cyber bullying, man-in-the-middle, phishing, privacy, online threats, mobile threats, etc., they will be equipped with knowledge and skills, which will empower them to make cyber-wise decisions and stay safe and secure in cyberspace.
And, just as I would never use my kung fu skills to harm someone, I expect all CyberShaolin graduates to use their cyber kung fu skills to create a secure future, for the good of humanity.

The Tools for Managing Open Source Programs guide provides an exhaustive collection of categorized tools that any open source program can benefit from.

Is your organization looking to build out an open source program? If so, you’re not alone, but not every organization has a holistic sense of the available tools that can help create a healthy program. A simple charter document and a few spreadsheets for tracking projects won’t cut it anymore in managing a truly robust open source program. That’s where the new Tools for Managing Open Source Programs guide comes in. It can help any organization launch and maintain a thriving open source program.

“If you have more than 100 code repositories or 100 people that you’re trying to manage, you really can’t have someone doing it manually with spreadsheets anymore,” notes Jeff McAffer, Director of the Open Source Programs Office at Microsoft, in the guide. “Obviously, people still do it that way. But it starts to become ad-hoc and laborious. That’s where tools come into play. They allow you to scale.”

While launching and maintaining an open source program does require dedicated, task-specific tools, it is a mistake to assume that your organization must necessarily build its own tools from the ground up.

“Regarding existing tools and systems, my hope is that we’re quickly getting to a point where a company’s open source program office should not need to create any tools or technologies on their own,” said McAffer. “They should be able to find and use existing open source tools which can be used to manage their open source programs.”

Categorized Tools

The Tools for Managing Open Source Programs guide provides an exhaustive collection of categorized tools that any open source program can benefit from. These include Source Code Scanning and License Compliance tools, Bug Tracking tools, Release Management tools, and more. Are you familiar with FOSSology? It’s a Linux Foundation project that functions as an open source license compliance software toolkit capable of running license, copyright and export control scans from the command line. Have you heard of Docker Hub? It’s a cloud-based registry service that allows users to link to code repositories and build and test their images. These and many, many more useful tools are linked to and explained in the free guide.

Do you know how to answer questions like these?

  • How are your project APIs documented?
  • Have you laid out a Contributor Licensing Agreement that everyone can use?
  • Have you picked the right license for your project?

Various tools can help you determine the right answers to these questions, and the Tools for Managing Open Source Programs guide is a great way to surface them.

Methodologies

It’s important to understand that using open source for business strategy requires its own methodologies and processes which are very different than those needed when using and releasing proprietary software. As the guide notes:

“Nobody said it was going to be simple to move your company into the world of open source. But plenty of other companies, including giants like Microsoft and Google have done this before you and have provided detailed road maps, code, suggestions, and more to make your own journey easier. The creation of an open source program office and the selection of a package of critical tools to get your efforts started are within your grasp. By collaborating on open source projects and inviting others to collaborate with you, your company can gain immeasurable benefits and drive its progress forward with energy and innovation.”

The Tools for Managing Open Source Programs guide is one of a new collection of guides from The Linux Foundation and The TODO Group that are all extremely valuable for any organization setting up an open source program. The guides are available now to help you run an open source program office where open source is supported, shared, and leveraged. With such an office, organizations can establish and execute on their open source strategies efficiently, with clear terms.

These guides were not produced in a vacuum. Far from it. The advice you will find in them grew organically out of many interviews with some of the world’s leading open source experts. We encourage you to check out the guides and stay tuned for our continuing coverage of them.

Also, don’t miss the first article in this series, on How to Create an Open Source Program, which explores everything from the role of the open source program office to how successful open source programs at companies like Google function.

 

Concepts such as decentralizing strategy, delegating direction, and fierce transparency in communication are part of the backbone of successful open source projects. In my presentation at Open Source Summit EU in Prague, I will explore how these concepts are not only applicable to volunteer-run organizations but can also help growing corporations avoid some of the coordination overhead that often comes with growing teams and organizations.

We’ll look at some of the key aspects of how project members collaborate at The Apache Software Foundation (ASF). After that, we’ll take a closer look at German FinTech company Europace AG, which decided to move toward self-organization two years ago. We’ll highlight parallels between Europace AG’s organizing approaches and those of open source projects.

Let’s start with some of the core values of ASF projects.

Community over Code

One main principle is the concept of “community over code” — which means that without a diverse and healthy team of contributors to a project, there is no project. It puts the team front and center, as highlighted in the Apache project maturity model.

Meritocracy

Another core value to Apache projects is meritocracy — essentially meaning that there is no governance by fiat. There is no way to simply buy influence into projects — you have to invest time to gain influence. This directly translates to frequently given advice for how to get started with any given project: Focus on the things you are using yourself and fix what bothers you most essentially following a scratch your own itch kind of model. There is one level of indirection here: Committers and contributors can be paid either by their employers or as part of a consulting gig to increase their motivation to work on the topics that you are interested in.

Project independence

Be aware though that there is a strong principle of people participating as individuals on projects. That level of independence means that within an Apache project, there is no way to assign tasks to project members. Apache projects by design have a very flat organization with barely any hierarchy: Titles like Project Management Committee Chair (PMC Chair) are famous for coming with additional responsibility but no entitlement to task assignment. That means projects need a process for aligning people with potentially very diverse interests and itches to scratch. A key ingredient to coming up with workable decisions is making project goals and needs public and transparent — both in terms of asking for help and in showing appreciation and rewarding contributions that help the project. Another one can be found in an approach to integrating differing opinions and arguments in a “Yes, and” instead of a “Yes, but” fashion. This plays together very closely with the next concept.

Full transparency in open source projects

“What didn’t happen on the mailing list, didn’t happen” is one of the mantras for those involved with Apache projects. A high level of transparency is what makes Apache projects so easy to participate in across boundaries — whether they are geographic, corporate, or other. At Apache, mailing lists are treated as the point of reference for any decisions made. Thus, there is full transparency into the historic record of all open source projects.

Of course, with that entirely open and transparent model comes responsibility: A lot of decisions can be taken in the open. People tend to show better behavior when under public scrutiny. However, discussions involving interpersonal issues are best kept out of public sight. This is particularly important in a digital age where deleting statements made online and mirrored worldwide is pretty much impossible.

Project autonomy

Technologically, Apache projects are very diverse. However, when unified under one organization with a common focus on community, meritocracy, and communication patterns, there is a lot of freedom and decentralized decision making.

One important piece in growing the ASF as a whole was giving autonomy to each project. Still there are a couple topics that each project has to deal with: It’s great having one central entity answering questions on, for example. trademarks, licensing, or software patents. However, these entities controlling each of the 300 or so top level open source projects won’t scale. Instead, Foundation-level services serve as guidelines for Apache open source projects to manage their own activities in these areas. As a result, each project is supposed to have some people knowledgeable in those topics.

Open source patterns in the enterprise

In the past decade, people in the open source space have successfully brought several of these concepts to their respective employers — either in the form of open development, inner source, or open organizations. Meanwhile, ideas of transforming traditional hierarchical organizations into self-organized, open organizations found their way into concepts like sociocracy and holacracy.

Europace AG decided to move toward self-organization roughly two years ago. Looking at what was established during these two years, we see quite a few similarities to how nonprofits such as the Apache Software Foundation and The Linux Foundation work with open source projects:

Decentralization and autonomy

Europace AG is a tech company experienced with XP and Scrum, and in 2015, they began a journey toward self-organization, looking into holacracy and sociocracy frameworks. Organizationally, there are roughly 200 people split into four fairly autonomous technical units, each one of which is responsible for one business product of the company. Units are autonomous in how they self-organize: Some chose fairly standard Scrum-based software development in iterations and standard rituals. Others went for sociocratic or holacratic models. By organizing in circles, employees are given more influence over how decisions are made that affect their daily work. Backing for this level of autonomy can be found in the company’s own principles, where self-organization and decentralization are outlined as one of the four important values and are actively supported by the board.

This is not unlike Apache, where open source projects operate independently and autonomously in how they develop their software and self-organize (that is, provided they make sure that project governance remains independent of one single player, security issues are being dealt with, and legalities like licensing, patent issues, and trademarks are taken care of).

Transparent decision making

Everyone working for and with Europace AG is located in one timezone, and Europace AG itself has only one site. Nonetheless, there are good reasons to look at how decisions are made in distributed open source projects: Establishing a remote friendly communication model can help support employees with family, and deal with long commute distances. Apart from these obvious benefits, there are a few effects that aren’t quite obvious:

While an asynchronous communication model won’t lead to decisions happening faster, it can help with reducing the amount of interruptions caused by face-to-face meetings: By sharing a proposal before the actual meeting happens and providing a means to exchange ideas around that proposal can help with understanding people’s opinions, issues and suggestions with respect to the proposal. It can help with making that understanding transparent to everyone interested in the topic up front. Combined with a “Yes, and” philosophy, this can help form consent in the team quickly.

Organizational Groups

Splitting roughly 200 employees into just four units creates groups that are bigger than typical “2 pizza sized teams” often deemed ideal for software development teams. As a result, each unit had to figure out how to create sub-groups that can work well as teams.

A common approach was to create cross-functional feature teams, comprising both software developers and people familiar with financial domain (and people with backgrounds in data analytics, UX, etc. as needed). Those are called feature teams in anticipation of the fact that they aren’t necessarily particularly stable: Each week, there is a check point people can use to decide to change feature teams depending on where they are needed most. Decisions related to governance as well as product strategic aspects are delegated to the team itself. As a result, team members need a good understanding of the current product direction in terms of features and usage.

For tasks and topics that tend to fall under the general topic of “organizational operations” or “decision making with dependencies,” people organize themselves in circles, which are essentially groups of people interested in participating in making a decision related to a specific topic. Despite a lot of communication still happening face to face, some circles also set up a Slack channel that is open for all to join and participate. This level of transparency is crucial in elevating trust people have in those decisions.

Each of these circles can come with dedicated roles: Secretary being the one taking over meeting minute creation, a Lead Link making sure that “things will actually get done” and communicated to the people needing the respective information. While people can volunteer for these roles, at the end of the day these roles get filled through nomination by the team. This is not unlike Apache projects where new committers, PMC members, and even Foundation members are elected after nomination. On one hand, this kind of model shows a certain amount of appreciation for the work these people are doing. On the other, it helps with promoting people into these roles who according to their own self-assessment might not have confidence to take on the role.

Put the human first 

Much like Apache puts community development front and center with its open source projects, Europace AG puts team collaboration into a central position. This means that each employee is responsible for raising issues with team climate, and they are supported by a team of professional coaches, moderators, and mediators with a deep understanding of human communication.

Conclusion

When moving toward self-organization, corporations can learn a lot from how open source projects organize themselves. Europace AG is on the journey toward moving more power away from traditional formal structures, making it available for the people in purpose-driven, circle-based organization. It will be interesting to watch how Open Source project management, governance, and communication patterns can be applied within corporate contexts.

Isabel Drost-Fromm is Open Source Strategist at Europace AG Germany. She is a member of the Apache Software Foundation, co-founder of Apache Mahout and has mentored several incubating projects. Isabel is interested in all things FOSS, search and text mining with a decent machine learning background.

At organizations of all types, launching and maintaining successful open source programs has become a business priority. A strong open source program office helps to ensure that open source is supported, nurtured, shared, explained, and leveraged. With such an office, organizations can establish and execute on their open source strategies in clear terms.

With all this in mind, The Linux Foundation and The TODO Group (Talk Openly Develop Openly) have published a free collection of detailed open source guides to aid companies developing open source programs. The guides are available to you now, and this is the first in a series of articles that can introduce you to the value of the guides.

How to Create an Open Source Program is the first of the guides, and it explores everything from the role of the open source program office to how successful open source programs at companies like Google function. The guide also includes insights and advice from open source experts, including John Mark Walker, Founder of the Open Source Entrepreneur Network, and Will Norris, Open Source Office Manager at Google.

“The open source program office is an essential part of any modern company with a reasonably ambitious plan to influence various sectors of software ecosystems,” notes Walker, in the guide. “If a company wants to increase its influence, clarify its open source messaging, maximize the clout of its projects, or increase the efficiency of its product development, a multifaceted approach to open source programs is essential.”

The How to Create an Open Source Program guide makes clear that there is not a one-size-fits-all approach to creating a successful program. In fact, Google’s Norris notes that stakeholders from individual business units play a key role in how open source projects advance at Google.

“We allow the various business units around the company to make the decision on whether it makes sense to open source a given project from a business perspective, because there’s a lot of different reasons why you might open source a project or a piece of code,” he notes. “We’re comfortable with allowing projects to take the approach that works for them given their goals. We play more of a role of facilitating and advising.”

The first guide lays out recommendations for how to include stakeholders ranging from Legal to Engineering in the maintenance of a program office. It also delves into the importance of setting clear program policies and observing compliance guidelines.

“Having a well-defined policy in place, that’s great, but it’s got to be a well-defined minimal policy,” said Jeff Mcaffer, director of the Open Source Programs Office at Microsoft, who was interviewed for the first guide. “Otherwise you get lawyers, security folks, business folks, all piling in their concerns and constraints. Soon you end up with a straitjacket full of policy that basically means that nobody can do anything.”

These free guides are extremely valuable for any organization setting up an open source program. Notably, the guides were not produced in a vacuum. Far from it. The advice you will find in them grew organically out of many interviews with some of the world’s leading open source experts. We strongly encourage you to check out the guides, and stay tuned to this space for more articles in this series.