Posts

This article explains how to walk through, measure, and define strategies collaboratively in an open source community.

“If you don’t know where you are going, you’ll end up someplace else.” Yogi Berra

Open source projects are generally started as a way to scratch one’s itch and frankly that’s one of its greatest attributes. Getting code down provides a tangible method to express an idea, showcase a need, and solve a problem. It avoids over thinking and getting a project stuck in analysis-paralysis, letting the project pragmatically solve the problem at hand.

Next, a project starts to scale up and gets many varied users and contributions, with plenty of opinions along the way. That leads to the next big challenge how does a project start to build a strategic vision? In this article, I’ll describe how to walk through, measure, and define strategies collaboratively, in a community.

Strategy may seem like a buzzword of the corporate world rather something that an open source community would embrace, so I suggest stripping away the negative actions that are sometimes associated with this word (e.g., staff reductions, discontinuations, office closures). Strategy done right isn’t a tool to justify unfortunate actions but to help show focus and where each community member can contribute.

A good application of strategy achieves the following:

  • Why the project exists?
  • What the project looks to achieve?
  • What is the ideal end state for a project is.

The key to success is answering these questions as simply as possible, with consensus from your community. Let’s look at some ways to do this.

Setting a mission and vision

Efforts and courage are not enough without purpose and direction.” John F. Kennedy

All strategic planning starts off with setting a course for where the project wants to go. The two tools used here are Mission and Vision. They are complementary terms, describing both the reason a project exists (mission) and the ideal end state for a project (vision).

A great way to start this exercise with the intent of driving consensus is by asking each key community member the following questions:

  • What drove you to join and/or contribute the project?
  • How do you define success for your participation?

In a company, you’d ask your customers these questions usually. But in open source projects, the customers are the project participants and their time investment is what makes the project a success.

Driving consensus means capturing the answers to these questions and looking for themes across them. At R Consortium, for example, I created a shared doc for the board to review each member’s answers to the above questions, and followed up with a meeting to review for specific themes that came from those insights.

Building a mission flows really well from this exercise. The key thing is to keep the wording of your mission short and concise. Open Mainframe Project has done this really well. Here’s their mission:

Build community and adoption of Open Source on the mainframe by:

  • Eliminating barriers to Open Source adoption on the mainframe
  • Demonstrating value of the mainframe on technical and business levels
  • Strengthening collaboration points and resources for the community to thrive

At 40 words, it passes the key eye tests of a good mission statement; it’s clear, concise, and demonstrates the useful value the project aims for.

The next stage is to reflect on the mission statement and ask yourself this question: What is the ideal outcome if the project accomplishes its mission? That can be a tough one to tackle. Open Mainframe Project put together its vision really well:

Linux on the Mainframe as the standard for enterprise class systems and applications.

You could read that as a BHAG, but it’s really more of a vision, because it describes a future state that is what would be created by the mission being fully accomplished. It also hits the key pieces to an effective vision it’s only 13 words, inspirational, clear, memorable, and concise.

Mission and vision add clarity on the who, what, why, and how for your project. But, how do you set a course for getting there?

Goals, Objectives, Actions, and Results

“I don’t focus on what I’m up against. I focus on my goals and I try to ignore the rest.” Venus Williams

Looking at a mission and vision can get overwhelming, so breaking them down into smaller chunks can help the project determine how to get started. This also helps prioritize actions, either by importance or by opportunity. Most importantly, this step gives you guidance on what things to focus on for a period of time, and which to put off.

There are lots of methods of time bound planning, but the method I think works the best for projects is what I’ve dubbed the GOAR method. It’s an acronym that stands for:

  • Goals define what the project is striving for and likely would align and support the mission. Examples might be “Grow a diverse contributor base” or “Become the leading project for X.” Goals are aspirational and set direction.
  • Objectives show how you measure a goal’s completion, and should be clear and measurable. You might also have multiple objectives to measure the completion of a goal. For example, the goal “Grow a diverse contributor base” might have objectives such as “Have X total contributors monthly” and “Have contributors representing Y different organizations.”
  • Actions are what the project plans to do to complete an objective. This is where you get tactical on exactly what needs done. For example, the objective “Have contributors representing Y different organizations” would like have actions of reaching out to interested organizations using the project, having existing contributors mentor new mentors, and providing incentives for first time contributors.
  • Results come along the way, showing progress both positive and negative from the actions.

You can put these into a table like this:

Goals Objectives Actions Results
Grow a diverse contributor base     Have X total contributors monthly
  • Existing contributors mentor new mentors
  • Providing incentives for first time contributors
Have contributors representing Y different organizations
  • Reach out to interested organizations using the project

In large organizations, monthly or quarterly goals and objectives often make sense; however, on open source projects, these time frames are unrealistic. Six- even 12-month tracking allows the project leadership to focus on driving efforts at a high level by nurturing the community along.

The end result is a rubric that provides clear vision on where the project is going. It also lets community members more easily find ways to contribute. For example, your project may include someone who knows a few organizations using the project this person could help introduce those developers to the codebase and guide them through their first commit.

What happens if the project doesn’t hit the goals?

“I have not failed. I’ve just found 10,000 ways that won’t work.” — Thomas A. Edison

Figuring out what is within the capability of an organization — whether Fortune 500 or a small open source project — is hard. And, sometimes the expectations or market conditions change along the way. Does that make the strategy planning process a failure? Absolutely not!

Instead, you can use this experience as a way to better understand your project’s velocity, its impact, and its community, and perhaps as a way to prioritize what is important and what’s not.

An important step in using open source code effectively is setting explicit guidelines to be followed.

Open source programs at organizations of all sizes are fueling innovation, and many program leaders are quickly learning that weaving open source code into projects — and creating new projects — require informed guidelines and best practices. Organizations are often leveraging existing open source code to build their own commercial products and services, and contributing back to projects.

However, diving in and using open source code without an understanding of everything from legal risks to best development practices is perilous. Approaching open source code usage without best practices in place can also tarnish an organization’s reputation. That’s where the free, new Using Open Source Code guide comes in. It can help you craft and codify a comprehensive strategy.

One of the most important steps in using open source code effectively within your program is to set explicit guidelines to be followed, which are often summarized in a strategy document. What if code comes into one of your projects from a project with a different licensing setup? What acceptance, rejection, and exception policies should developers follow? What is your organization’s overall stance toward open source development?

These are all among the questions that need concrete answers as you codify your strategy, and there are more questions involving the ecosystem that applies to using open source code. How are APIs documented? Have you laid out a Contributor Licensing Agreement that everyone can use? Have you picked the right license for your project? Your strategy document should be specific about best practices, APIs and more.

“A well-designed open source compliance process should simultaneously ensure compliance with the terms of open source licenses and also help companies protect their own intellectual property and that of third-party suppliers from unintended disclosure and/or other consequences,” notes Ibrahim Haddad, Vice President of R&D and Head of the Open Source Group at Samsung Research America.

Creating a Policy

As the guide notes, creating a strategy document featuring best practices does not need to be complicated. A good open source usage policy includes six simple rules:

  • Engineers must receive approval from the OSRB before integrating any open source code in a product.
  • Software received from third parties must be audited to identify any open source code included, which ensures license obligations can be fulfilled before a product ships.
  • All software must be audited and reviewed, including all proprietary software components.
  • Products must fulfill open source licensing obligations prior to customer receipt.
  • Approval for using a given open source component in one product is not approval for another deployment, even if the open source component is the same.
  • All changed components must go through the approval process.

Importantly, the guide also notes the importance of effective code review practices. “If your code review process is overly burdensome, you’ll slow innovation or provide a good excuse for developers to circumvent the process completely,” Haddad emphasizes.

Additionally, Haddad, advises that circumspect code usage and compliance practices must be ongoing. “It’s important to remember that open source compliance doesn’t stop with version 1.0,” he said.

The Using Open Source Code guide can help you with everything from licensing issues to best development practices, and it explores how to seamlessly and safely weave open components into your open source projects. It is one of a new collection of free guides from The Linux Foundation and The TODO Group that are all extremely valuable 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 establish and execute on their open source strategies efficiently, with clear terms.

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

Also, 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

A Free Guide to Participating in Open Source Communities

Read about featured Linux kernel developers in the 2017 Linux Kernel Development Report.

The recent Linux Kernel Development Report released by The Linux Foundation, included information about several featured Linux kernel developers. According to the report, roughly 15,600 developers from more than 1,400 companies have contributed to the Linux kernel since 2005, when the adoption of Git made detailed tracking possible. Over the next several weeks, we will be highlighting some specific Linux kernel developers who agreed to answer a few questions about what they do and why they contribute to the kernel.

Linux kernel developer

Laura Abbott, a Fedora Kernel Engineer at Red Hat

In this article, we feature Laura Abbott, a Fedora Kernel Engineer at Red Hat.

The Linux Foundation: What role do you play in the community and what subsystem(s) do you work on?

Laura Abbott: My full-time job is working as one of two maintainers for the Fedora kernels. This means I push out kernel releases and fix/shepherd bugs. Outside of that role, I maintain the Ion memory management framework and do occasional work on arm/arm64 and KSPP (kernel hardening).

The Linux Foundation: What have you been working on this year?

Abbott: I did some major reworking on Ion this year and ripped out a lot of code (everyone’s favorite type of patch!). Hopefully, I’ll be able to report that Ion is out of staging in the next kernel report. Apart from that, I’ve spent a lot of time testing and reviewing patches for kernel hardening.

The Linux Foundation: What do you think the kernel community needs to work on in the upcoming year?

Abbott: As a general theme, there needs to be a focus on scaling the community. There’s always an ongoing discussion about how to attract new developers and there’s been a recent focus on how to grow contributors into maintainers. There’s still a lot of ‘tribal knowledge’ in pretty much every area which makes things difficult for everyone. I’d like to see the kernel community continue to make processes easier for new and existing developers. I’d also like to see the discussions about building an inclusive community continue.

The Linux Foundation: Why do you contribute to the Linux kernel?

Abbott: I’ve always found low-level systems fascinating and enjoy seeing how all the pieces work together. There’s always something new to learn about in the kernel, and I find the work challenging.

You can learn more about the Linux kernel development process and read more developer profiles in the full report. Download the 2017 Linux Kernel Development Report now.

open source program

“We believe that our projects help move the industry forward while giving other companies and individuals the opportunity to use our platform to scale more quickly and build better products.” – Christine Abernathy, Open Source Developer Advocate at Facebook.

Facebook’s open source team was “formally” created in 2009, but the company has built with open source from its inception. Facebook.com was originally built on top of the LAMP (Linux/ Apache/ MySQL/ PHP) stack. And over time Facebook has used and contributed back to these projects, as well as evolved and released new projects such as Hack which has its roots in PHP.

“Open source is core to our engineering DNA. We believe that sharing our code and even hardware designs accelerates the pace of innovation in the world. We believe that our projects help move the industry forward while giving other companies and individuals the opportunity to use our platform to scale more quickly and build better products.” – Christine Abernathy, Open Source Developer Advocate at Facebook.

Custom tools to manage open source

Facebook has a dedicated Tools team within the open source program office that is responsible for building internal tools to help manage its open source portfolio. This includes the projects that Facebook shares, which are mostly hosted on GitHub, as well as the other external projects they contribute to such as the Linux Kernel.

The program office provides a dashboard for each project that includes GitHub metrics such as the number of open issues or the ratio of internal to external contributions for a given time period. Project maintainers are given tools so they can bring GitHub pull requests and issues into their internal review and bug tracking systems. This makes it easier for engineers to manage external issues where they’re most comfortable. Maintainers also have access to workflow tools to reliably push internal commits out to GitHub, making it easy to quickly sync internal and external code bases and reducing the churn on landing external contributions.

The open source team can look at these project dashboards to help analyze the health of a particular project. They’ve even open-sourced some of these workflow tools: mention-bot and FBShipIt.

The team collects top-level statistics on how the overall portfolio is doing through aggregate dashboards across the GitHub orgs they manage. These are used to provide high-level reports to stakeholders and a community of internal open source enthusiasts. The tools team also provides insight into top contributors. Project maintainers are encouraged to refer to this list and reward their top contributors. The company periodically thanks its top internal contributors and makes some of this information available to its internal review systems.

The open source office also provides tooling to guide potential projects through the review process. This helps streamline the process and helps the team easily spot and correct bottlenecks.

The open source team also provides services such as documentation. This includes helping out with the technical content as well as building out some of the documentation infrastructure and templates that projects can use.

Open Source Success Through Steady Progress

At the end of each half the program office identifies goals around metrics they want to achieve. The metrics they track include:

  • The average age of open issues or open pull requests
  • The ratio of external to internal commits
  • The number of commits
  • The growth in followers and forks
  • The number of social media followers.

They’re periodically tweaking what they measure as they refine what it means to maintain a healthy portfolio.

Facebook also surveys new hires every six months to gauge their awareness of its open source program. They set baseline metrics a few surveys back and the goal is to maintain or grow those numbers.

Their open source success isn’t the result of one action but the cumulative effect of a steady stream of quality releases over the years and a focus on growing thriving communities to support those projects.

“Projects like React, React Native, Create-React-App, Immutable, HHVM, Fresco, and GraphQL are the constant beat that have contributed to the success of our program,” Abernathy said.

One of Facebook’s most successful projects is React Native. It makes use of many of Facebook’s tools to help manage the community. For example, mention-bot came out of this project and was a way to quickly identify reviewers for a pull request. FBShipIt helped it cut down the time to bring in external contributions, review them internally, and land these contributions back out to GitHub. In the early days, this process sometimes took a day as much of it is manual. Now this can be done in as little as minutes if it’s an automatic reviews.

The open source program office also provided documentation services to help refresh and keep the React Native site up to date.

Tips for New Open Source Program Managers

Organizations that are just establishing an open source strategy and program office can learn from the success of Facebook’s open source program. Here are the three key practices that Abernathy shared that have contributed to their success as a program office:

  1. When evaluating what to share, it should be something that’s useful to your company. Many of the projects that Facebook shares are used in production and include all the benefits that come along with that. This means those projects are likely to have continued support which in turn means the community is well supported.
  2. Find a way to highlight, promote, and reward your open source contributors, both internal and external. Facebook has periodic reports that highlight its open source heroes. This helps raise the profile of engineers and their work with managers who may sometimes not be managers of that open source project.
  3. As a central program office, find pain points that cut across the various projects and tackle them.

For example, many projects had previously built their own commit copying scripts and it was the number one pain point from a survey they ran at that time. FBShipIt, which copies commits between repositories, was built to address this and it’s owned by the open source team. It moved the burden off the engineering teams and is universally praised for helping smooth the workflow for pulling in external contributions.

Acknowledgments

For this feature we interviewed Christine Abernathy (@abernathyca), Open Source Developer Advocate at Facebook, to learn more about the Facebook’s open source program. Libby Clark performed the interview.

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

“Recruiting Open Source Developers” is a free online guide to help organizations looking to attract new developers or build internal talent.

Experienced open source developers are in short supply. To attract top talent, companies often have to do more than hire a recruiter or place an ad on a popular job site. However, if you are running an open source program at your organization, the program itself can be leveraged as a very effective recruiting tool. That is precisely where the new, free online guide Recruiting Open Source Developers comes in. It can help any organization in recruiting developers, or building internal talent, through nurturing an open source culture, contributing to open source communities, and showcasing the utility of new open source projects.

Why does your organization need a recruiting strategy? One reason is that the growing shortage of skilled developers is well documented. According to a recent Cloud Foundry report, there are a quarter-million job openings for software developers in the U.S. alone and half a million unfilled jobs that require tech skills. They’re also forecasting the number of unfillable developer jobs to reach one million within the next decade.

Appeal to motivation

That’s a problem, but there are solutions. Effective recruitment appeals to developer motivation. If you understand what attracts developers to work for you, and on your open source projects (and open source, in general) you can structure your recruitment strategies in a way that appeals to them. As the Recruiting Open Source developers guide notes, developers want three things: rewards, respect and purpose.

The guide explains that your recruitment strategy can benefit greatly if you initially hire people who are leaders in open source. “Domain expertise and leadership in open source can sometimes take quite a long time at established companies,” said Guy Martin, Director of Open at Autodesk. “You need to put training together and start working with people in the company to begin to groom them for that kind of leadership. But, sometimes initially you’ve got to bootstrap by hiring people who are already leaders in those communities.”

Train internal talent

Another key strategy that the guide covers is training internal talent to advance open source projects and communities. “You will want to spend time training developers who show an interest or eagerness in contributing to open source,” the guide notes. “It pays to cultivate this next level of developers and include them in the open source decision-making process. Developers gain respect and recognition through their technical contributions to open source projects and their leadership in open source communities.”

In addition, it makes a lot of sense to set up internal systems for tracking the value of contributions to open source. The goal is to foster pride in contributions and emphasize that your organization cares about open source.  “You can’t throw a stone more than five feet in the cloud and not hit something that’s in open source,” said Guy Martin. “We absolutely have to have open source talent in the company to drive what we’re trying to do moving forward.”

Startups, including those in stealth mode, can apply these strategies as well. They can have developers work on public open source projects to establish their influence and showcase it for possible incoming talent. Developers have choices in open source, so the goal is to make your organization attractive for the talent to apply.

Within the guide, Ibrahim Haddid (@IbrahimAtLinux) recommends the following strategies for advancing recruitment strategies:

  1. Hire key developers and maintainers from the open source projects that are important to you.
  2. Allow your developers working on products to spend a certain % of their time contributing upstream.
  3. Set up a mentorship program where senior and more experienced developers guide junior, less experienced ones.
  4. Develop and offer both technical and open source methodology training to your developers.
  5. Participate in open source events. Send your developers and support them in presenting their work.
  6. Provide proper IT infrastructure that will allow your developers to communicate and work with the global open source community without any challenges.
  7. Set up an internal system to track the contributions of your developers and measure their impact.
  8. Internally, plan on contributing and focus on areas that are useful to more than one business unit/ product line.

The Recruiting Open Source Developers guide can help you with all these strategies and more, and it explores how to weave open source itself into your strategies. It is one of a new collection of free guides from The Linux Foundation and The TODO Group that are all extremely valuable 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 establish and execute on their open source strategies efficiently, with clear terms.

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

Also, don’t miss the previous articles in the series: How to Create an Open Source Program; Tools for Managing Open Source Programs; and Measuring Your Open Source Program’s Success.

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.

 

The upcoming APIStrat conference – Oct. 31-Nov. 2 in Portland – features three days of technical sessions, keynotes, and workshops.

The API Strategy & Practice conference (APIStrat) – taking place Oct. 31 through Nov. 2 in Portland – features three days of technical sessions, keynotes, and more, including several workshops providing hands-on learning opportunities. These sessions cover topics such as RESTful API integration, OpenID Connect, API security, and REST API testing.

Check out the following workshops happening at APIStrat:

Connect Your RESTful API to Hundreds of Others in Minutes (Zapier and other Integration Platforms) – Sean Matthews, Left Hook Digital

In this workshop, the Left Hook team will show how to connect your app to hundreds of others on Zapier’s platform in a matter of minutes. We’ll walk you through a quick integration, and then talk about the pros and cons of 30+ different integration platforms out there, as well as highlighting platforms upon which developers can build out their own API connectors today.

Creating Communication Applications using the Asterisk RESTFul Interface (ARI) – Chris Howard, Digium

The Asterisk RESTFul Interface (ARI) is an asynchronous API that lets developers build communications applications by exposing the raw primitive objects in Asterisk – channels, bridges, endpoints, media, etc. This presentation will provide information on getting started using ARI and provide a working demonstration of using the ARI to create a telephone application.

From 0 to  000s – Starting and Growing your Developer Program – Caroline Lewko, WIP

Learn the basics of starting a developer program from segmentation and polishing your personas, along with the seven most important onboarding activities. We will also include some extra special super sensory developer experience techniques.   

How Mature are You? A Developer Experience Maturity Model – Jenny Wanger, Arity, founded by Allstate

At Arity, we developed a maturity model for API programs to help you focus your time and effort on the areas that will provide the greatest value for your customers. We’ll go through the model together so you can score your company’s program. You’ll leave the session with a score and roadmap of how this can help you influence your stakeholders.

OpenID Connect Done the Right Way – Vinay Bhalerao, Red Hat

With the rise of mobile applications, OpenID Connect adoption has increased in the API market and is the preferred choice in API security. This workshop will help people to understand the differences between OAuth, JWT, and openID Connect and when to use the respective flows.

OWASP’s Latest Category – API Underprotection – Skip Hovsmith, CriticalBlue

In this workshop, you’ll learn about potential threats resulting from undersecured web APIs. You should gain a good understanding of the underprotected API problem, learn practical tips to improve your API security posture, and gain a sense of emerging tools and technologies that enable a significant step change in API security.

Simplify and Scale Your Connections To Data – William Broza, BitScoop Labs

The BitScoop platform radically simplifies data integration and streamlines the data and services development process with unified access to APIs, microservices, and more. Learn how to unify all internal and external data in your ecosystem under one API or SDK using our powerful and feature-rich iPaaS.

Starting with GTK – Julita Inca, UNI

GTK is a toolkit to create GUIs based on C program language. Glib and clutter are other technologies involved with GTK, and in this workshop, we’ll look at interactions with databases that support Linux (Fedora 25), such as SQLite or PostgreSQL. We can achieve at least four forms with an interaction of a database to build a system to register people in an event.

Super-Powered REST API Testing – James Messinger, Postman

In this workshop, I’ll show you just how easy – and dare I say, fun – it can be to test REST APIs. Whether you prefer the command line, a text editor, or a GUI, there are tools that will fit nicely into your workflow. Plus, you’ll leave with sample code and a working demo to get you started.

See the full APIStrat schedule here and register now!

The Linux operating system was created some 26 years ago by a young Finnish engineer, and it now powers the global economy. Not only has Linux survived for more than quarter of a century, it continues to grow its influence and dominance.

Not all open source software projects thrive, however; many promising projects die untimely deaths. So, what’s unique about projects like Linux that thrive where others fail? What’s the secret sauce that sustains one project over others? Is it the community? The license? The code? The organizations backing it?

We talked to open source veteran Brian Behlendorf, co-founder of the Apache Software Foundation (ASF) and current Executive Director of the Hyperledger project, for some answers to these questions. Here is an edited version of the interview conducted at Open Source Summit North America in Los Angeles.

What are the core components of sustainable open source projects?

Brian Behlendorf: By definition, any open source project that is still alive needs some critical mass of developers contributing to it.  The Linux kernel is 25+ years old, and it still sees 5,000 new lines of code every day. It’s still such an incredibly active project.

In my book, that means you need this body of maintainers and contributors who are willing to continue to nurture the project even as it goes into adolescence and later life.

For me, the only way to more or less guarantee that happens is to see that there are companies out there who are making money off of open source software. They have embedded it at the core of their business. And even if it’s not what they do as a business, it’s still something that they need. So they’ll provide feedback, contribute, and continue to invest in shepherding it forward.

So, having companies use and contribute to your project and in return inject resources does help. What role do non-profit organizations like The Linux Foundation and ASF play?

Behlendorf: What The Linux Foundation, I think, has figured out, is how to identify these technology spaces, bring companies together around them, and then help them make money from it and profit from it.

But it’s not the only viable model. The Apache Software Foundation model is entirely volunteer driven, with developers even doing things like running the books or doing marketing.

There’s an incredibly empowering side to that, but it doesn’t always work. There weren’t enough developers who showed up around OpenOffice, for example, for that to work for the Apache OpenOffice community.

It’s almost hard to say if any model is better than the others. They’re all very unique for the kind of software being built and the developers who are attracted to that software.

You talked about commercialization of open source, yet we have seen that some open source communities are averse to the idea of any commercial or corporate links.

Behlendorf: I don’t think there was really ever a truly long tradition of a battle between open source developers and commercial interests. I think many of the people I know who were contributing to open source even before me were building businesses on top of it. Michael Tiemann built Cygnus on top of the GNU compiler suite. So this template, and every ISP, every web business is building on top of open source web components.

I think the real battle might have been between proprietary software and free software. And the real question was, did we need to vanquish proprietary software in order for free software to flourish?

Do licenses play any role in sustainability of open source projects?

Behlendorf: I tend to think of companies that have played games with licensing. There’s not a lot of successful examples out there. Why don’t we just put these kind of games to the side? Let’s build the software we need together, and go out and build great applications and great websites and great other things on top of that.

And this is what we carried forward in the Hyperledger project as well. All the Hyperledger code is under an Apache license. All of it is designed to be embedded inside of other people’s products and services.

We want to see lots of cloud hosts running Hyperledger technology. We want to see a lot of application developers embedding this inside and, say, putting it inside of cars or IoT sensors or those sorts of things. The less time that we have to spend with lawyers and with MBAs explaining to them how and why they can make money with this code, the better off we all are.

Diversity is necessary for the survival of organisms, can the same be said for open source projects?

Behlendorf: If your community doesn’t look like the global community, then something’s wrong. 

The blockchain movement is a great example of diversity. India and China and Europe have been running as fast with this technology as anybody in the United States. We are constantly looking at what countries are we visiting. Where are our companies based? How do we go and empower those companies in a country like China or a country like India, to go and be champions of what they’re doing, of the technology that they’re building?

What about culture?

Behlendorf: I’d say the final thing I’d throw out about sustainability is if your project isn’t comprised of people who are nice to each other, it’s not going to be very sustainable. Even the smartest people, even the most enthusiastic people will burn out if the dynamic in the community is very harsh, or if every time a good idea is brought up you hear crickets or somebody talks it down. You need to be nice to each other on an open source project in order to have any hope of being sustainable.

This week in OSS and Linux news, two opinion writers at The New York Times consider the safeguards of open source software in future elections, Prodip Sen of HP shares the growing role of OPNFV, and more! Read on to stay in the open source know this week. 

1) The National Association of Voting Officials is leading a movement to encourage officials to stop purchasing insecure systems and use open source software to “guard our votes against manipulation.”

To Protect Voting, Use Open-Source Software– New York Times

2) As NFV becomes more central in transitioning to 5G, so too does OPNFV.

OPNFV’s Role in NFV Testing and the Road to 5G– Telecom TV

3) Microsoft continues trend towards being more open with new CNCF Platinum membership.

Microsoft Expands Role In Cloud By Joining Cloud Native Computing Foundation– Forbes

4) Windows 10 users will be able to run an array of Linux software this Fall.

Windows 10 Will Let Everyone Run Linux Inside Windows Following Fall Creators Update– TechRepublic

5) The effort to save Adobe Flash continues.

GitHub Developer Starts Petition to Open Source Adobe Flash– Computer Business Review