Posts

Building a successful open source community

Why do you need program management as part of your open source project? We asked a few of the Linux Foundation’s program managers to tell us how they each approach the task.

How does coordination and facilitation help improve my project? 

We tend to think of the primary goals of the Linux Foundation’s projects as producing open software, open hardware, open standards, or open data artifacts — the domain of participating programmers & engineers, system architects, and other technical contributors. 

However, successful projects engaging a broader ecosystem of commercial organizations, particularly when raising funds, benefit from active leadership besides pure technical contributions. Contributors often have work outside the project that often puts demands on their time. It takes real time to build and coordinate a commercial ecosystem, ensure stakeholders are engaged, recruiting and onboarding members, create a neutral governance culture (often amid competitors competing), and to keep various aspects of the ecosystem aligned such as when end users begin to participate.

Many Linux Foundation projects fundraise to provide resources for their community. This is an excellent benefit for the technical community when the business ecosystem comes together to invest and help the community obtain resources to build a thriving community and ecosystem. A typical fundraising model in our community is to offer an annual membership structure that provides a yearly fund for the project. 

The Linux Foundation’s approach to governance separates decisions about funds and business affairs from the technical project’s governance. The companies contributing money to a project’s fund can decide how those funds are spent and any related business decisions. The technical community can operate independently with open source best practices and continue to make decisions about what code to accept, how to build releases, etc. based on the technical merit of decisions in front of them and not based on what companies contributed funding.

We will always have representation from the technical community involved in the budget and business decisions to ensure funding decisions are well informed. This is how the Linux Foundation model preserves the development best practices of open source while enabling a community to benefit from the commercial ecosystem dependent on their work.

Guidance for your community

Within a technical project, there are roles for organizing how releases are built. Often some committers decide which code is accepted, and maintainers decide what to put into a release.  When scaling the project to create an ecosystem around it, there are other key roles and responsibilities that a project needs to stay on track and to continue to scale. These functions include:

    • Planning and Building.  Building a cohesive strategy is critical to the success of a project and requires investments in outcomes the core stakeholders want to see happen, and prioritize
    • Measuring KPIs. Tracking a project’s mission, goals, and objectives while moving those through the swim lanes is key to iterating on things that work and addressing things that don’t.
    • Facilitating. To be successful at facilitating, a coordinator must understand the landscape, and remain neutral. This can be difficult and is often the most challenging part of the job, NOT weighing in unless asked. 
    • Advising. Coordinators are a sounding board for these things with some expertise. To mature an organization, you must craft mechanisms for self-governance and sustainability.
    • Iterating and Reflecting. What happens along the way is that stakeholders in the community want to get things done — but when that happens without reflection, you lose sight of what and where you’re going. It’s essential to see the forest AND the trees, especially from an above-the-canopy view.

In the past, we have had a few communities with respected, neutral leaders who have provided these roles. The Xen Project is one example of a member of the community who has offered to perform this role for many years. There is a significant time investment from the community’s leadership to make it work, which is an excellent benefit for the community to have someone able and willing to spend their work time on this function. 

Many other projects are not able to find someone in the community to help. This is often where the Linux Foundation builds a support program to assist the projects we host that need help to obtain neutral coordination and facilitation professionals. We call the people who provide this support Program Manager (PM). PMs are often the first point of contact for community participants and potential members, and are usually involved in the following activities:

    • Program Managers help the governing and technical boards shape the project’s directions and goals. 
    • Program Managers will work with a project’s technical leadership to understand their technical goals. 
    • They work with the members to fill positions such as Chair and Treasurer and are involved with the voting process.
    • They ensure that both the governing and technical boards act within the agreed-upon guidelines of the project’s charter. 
    • They help onboard new members into the project community. 
    • They will engage resources from the Foundation’s Marketing, PR, Events, and Training teams to coordinate the support programs delivered for a project.  
    • Program Managers also oversee the delivery of other support programs provided by the Foundation and any services provided by vendors or contractors.
    • Program managers will pull in the Foundation’s IT service team members for a consultative discussion on the right development infrastructure, tools, and managed IT support programs based on the project community’s needs and roadmap. 
    • Program managers actively engage in community management and help the project’s leaders coordinate meetups, developer hackfests, and participation at events.

Setting strategic goals for your community

Identifying and articulating a project’s mission is essential with an open source project as it is with any business activity. Setting concrete goals enables the participants in a project to discuss and align around a single narrative that can guide their activities and inform decisions. 

Program Managers work with the project’s membership and technical leadership to define a strategy with goals, milestones, and metrics for the project. They coordinate discussions to assist the governing board in coming to a consensus on a budget that supports the technical community’s needs and aligns with the project strategy. 

For open source, very often, the goals include maximizing a project’s footprint in order to help the most people. Goals are often articulated to a fine granular level — enabling contributors to engage more easily, growing the membership from a particular sector of the ecosystem, or increase contributions from end users. 

The CHAOSS project is a community focused on defining community metrics around engagement, risks, etc. that are often helpful to project leaders in setting and establishing goals for measurably improving their ecosystem. 

Implementing a project lifecycle for your community

Open source projects often have subprojects and various efforts to innovate on new ideas that may not be ready to be included in an official release or as their independent release. We often refer to these communities as using an “umbrella” model with several coordinated sub-projects within the community. Within an umbrella community, the projects will typically follow a lifecycle. The lifecycle generally follows a path from imagination to planning to initial execution, expansion, and eventually maintenance and eventual retirement. 

Program managers often work with the technical leadership to codify this lifecycle according to milestones so that participants in the project can immediately understand where a project stands in terms of maturity and resources. CNCF, for example, has project phases that include Sandbox, Incubation, and Graduation. OpenJS Foundation has project phases that include Incubation, At-Large, Growth, Impact, and Emeritus, which map to the needs of their community.

A project lifecycle is an essential tool for a foundation to signal the maturity of multiple projects and identify for the community what the path towards a fully mature project requires. It is both a pathway and a signal, noting that projects grow and change, and what the community thinks a project should rely on to guide itself. 

In most projects, there is an entry-level, a mid-level, and a graduate level. The entry-level projects indicate a promising start for an emerging project and something to be considered. Mid Level projects show growth and development for an audience that might consider using this project, and graduated projects indicate full maturity and a project that many in the ecosystem rely upon.

“Within the Cloud Native Computing Foundation, the various project stages have been beneficial for encouraging projects to grow, not only from a development standpoint but from a community standpoint. A project looking to graduate has to demonstrate both a strong codebase and a strong community.”

Amye Scavarda Perrin, CNCF Program Manager

Linux Foundation Networking (LFN) Program Manager Trishan De Lanerolle notes how the Technical Advisory Council plays an active role in a project’s lifecycle management:

“Linux Foundation Networking project (LFN) technical leadership (Technical Advisory Council) developed and published a model that lays out criteria and checkpoints for projects in various stages of maturity, including an LFN Entry review and evaluation for new candidate projects to the LFN umbrella. The entry process provides a mechanism to amicably and fairly assess upcoming projects. In LFN, that entails asking whether a proposed project: falls within the LFN scope, provides a snapshot into the status or health of the community, and ensures the project’s documented governance is clear, complete, and easily accessible.”

Through facilitating the work of the Strategy Subcommittee, whose primary goal is to assist the Governing Board with developing and implementing Continuous Delivery Foundation (CDF) strategic planning, Program Manager Dan Lopez was able to guide CDF toward sustainable, long-lasting strategic goals. 

“The immense value of a Program Manager lies in their ability to foster a space for progress to happen. It’s not their role to necessarily make the tough decisions, but rather be the ‘glue’ of a program, ask the tough questions, and spark inspiration and critical thinking within their stakeholder group to create, in this case, sustainable goals that will create long term value for the CDF,”

Dan was able to approach strategic planning, as a neutral party who understood the landscape of the CDF, and assist the Governing Board in creating well-aligned goals that mapped to key performance indicators that can be measured and managed over time. 

The importance of open governance in your community

The Program Manager is also a vital member of the leadership team, working collaboratively to facilitate and operationalize the wants, needs, and priorities of the governing bodies. Each Linux Foundation Program Manager works with each project community to establish a transparent, open governance model for the technical community.

In open governance, a project is managed by a group of people representing the stakeholders in a project — generally project members and leaders of the project’s technical efforts. The concept of conducting a major technical effort using an open form of governance, in which all stakeholders’ needs must be addressed, and people are required to cooperate to get work done, is founded on the basic concept of democracy. It differs from closed or proprietary governance due to the transparency and coordination required to reach consensus.

Open governance provides a balance that can never be found in a proprietary, restrictive environment — the dynamics of that activity drive creativity and innovation, and significantly increase the speed of development. Program managers and community managers often guide these processes and help keep governance bodies on track with each other.

DPDK’s Program Manager Trishan de Lanerolle discusses how his project is divided into two bodies of equal responsibility:

“DPDK is one model of open governance, with co-equal governing bodies; the Governing Board has ownership and oversight, over budget, marketing, lab resources, administrative, legal, and licensing issues, and a Technical Board with ownership and oversight on technical issues including approval of new sub-projects, deprecating old sub-projects, the project’s technical roadmap, recruiting maintainers, defining the processes for contributing, testing, and managing security. The Technical Board comprises individuals from various organizations, that are not necessarily corporate members of the project, recognized for their technical contributions. The governing board comprises representatives from member organizations, who financially support the project, working hand in hand to make the project mission a reality.” 

Other projects, such as LF Energy, take a somewhat different path towards how their governance is structured. 

LF Energy represents an example of open, representative governance within a rapidly growing open source foundation. LF Energy has a board of directors, like most foundations, made up of Premier members, and includes a representative from the General members and a representative from the Technical Advisory Council (TAC), which is made up of technical project leaders. No single company has more than one representative on the board, which provides corporate as well as cultural diversity and voices from all over the industry, not just focused on one niche. 

The Linux Foundation’s neutral program management support program can help

Active program management and program management support is one of the main reasons why open source projects join an organization like the Linux Foundation. Our program management professionals provide a unique set of operational skills and capabilities that nearly all of our projects take advantage of — which is to offload operational and facilitation work from the community. 

In summary, a successful project should have community coordination and program managers that can plan and build, that can measure a project’s performance, that can act as prime facilitators and advise, and can help project stakeholders iterate and reflect to learn from their experiences in order to move a project forward.

“Managing Open source projects can be compared to nurturing a young sapling as it grows into a mature, healthy tree — or in this case, a community. Our job is to supply it with the right balance of nutrients and conditions for successful growth. Following proven governance models with strategic program management, helps increase the odds of nurturing a healthy community. Program Managers help clear the path, allowing communities to focus on the code and achieving technical goals. We are horticulturalists, toiling away in the background, and if we are doing our job correctly, you shouldn’t notice us.” 

Trishan de Lanerolle, Technical Program Manager & Community Architect, LF Networking

FINOS Joins the Linux Foundation

Introduction

This week we are excited to announce that FINOS, the Fintech Open Source Foundation, is joining our Linux Foundation community of projects. With critical financial services projects under its stewardship, FINOS has become the hub for open collaboration in the financial services industry. FINOS serves similar needs to other vertical industry communities at the Linux Foundation, such as the Academy Software Foundation focused on the motion picture industry, Automotive Grade Linux focused on the automotive industry, and others. With FINOS at the LF, we are excited for the many cross community collaboration opportunities. 

What is FINOS and What Challenges is it Helping Financial Services Firms Address?

FINOS’  purpose is to accelerate collaboration and innovation in financial services technology through the adoption of open source software, standards and best practices.

FINOS is composed of over 30 member organizations, developing software and standards for data and data technologies, cloud services, financial desktop applications, and more. It is unique among open source foundations in that it is an open community for financial services and fintech firms to address unique industry challenges, as opposed to being horizontal across industries.

Financial services firms face unique obstacles to open source collaboration, including legal & regulatory concerns, internal policies, cultural friction, and heavily restricted technology environments. FINOS is a path to working outside corporate boundaries with others in the industry that are trying to solve the same problems.

In order to more efficiently leverage open source, FINOS supports its members every step of the way starting with its Open Source Readiness Project, providing guidance and tools for financial services participants new to open source. 

In addition to providing reference guides and policy templates that financial organizations may use in adopting open source software, FINOS provides tools that include frameworks and underlying shared code for creating the foundational backbone & infrastructure, middleware, data and application layers for open source financial applications. 

To assist in the consumption of these tools, FINOS also runs regular readiness meetings to help financial services organizations discuss common challenges, share successful experiences and more broadly prepare for the adoption of open source software.

Why Does the Financial Services Industry Need Open Source Software and Organizations Such as FINOS? 

As with other vertical industries, the financial services industry can realize the same benefits by adopting open source technologies. This is achieved by reducing overall total cost of ownership by sharing the development of common software components and underlying technology infrastructure through mutualization — this allows financial services and fintech firms to quicken their time to market for their services and product offerings and improve overall software quality. 

Having a broader pool of developers working on open source financial software enables financial services companies to attract and retain talent from a larger pool. Embracing open source software also allows IT stakeholders and decision-makers in financial services organizations to de-risk software investments by reducing vendor lock-in, and fostering internal and external re-use of software components. 

Additionally, open software and open standards can dramatically simplify workflow integration and improve interoperability between financial institutions, counterparties, and even regulators. This increases firms’ ability to meet rapidly changing client and regulatory needs more quickly and seamlessly.. Ultimately, FINOS seeks to create a “build once” approach to many aspects of financial technology solutions and leverages its community experts and active board-level engagement  from a wide range of prominent leaders within finance. 

Finally, it enables financial and technology firms working in this space to learn about high-value and industry-wide business challenges that can inform and validate product and project roadmaps.

FINOS Project Highlights

The value of FINOS is expressed through its many programs and services, which include, but are not exclusive to these open source software and open standardization projects:

The FINOS open source software project landscape. Image Credit: FINOS

The FINOS open source software project landscape. Image Credit: FINOS

FDC3: Launched in 2017 by OpenFin in collaboration with major industry participants, FDC3’s mission is to develop specific protocols and taxonomies to advance the ability of desktop applications in financial workflows to operate in a plug and play fashion, without prior bilateral agreements. Under the neutral FINOS umbrella, and now the Linux Foundation, FDC3 is now widely adopted and has received contributions from several banks, buy-side firms, consultancies, and financial technology vendors.

A sample FDC3 application.

A sample FDC3 application. Image Credit: FINOS

Plexus: Contributed to FINOS in 2017 by Deutsche Bank and developed in the open as part of its production Autobahn platform, Plexus defines an open standard for desktop application interoperability with a container-agnostic reference implementation. This enables seamless workflows between independent apps developed by different organizations in different technologies. The project aims to be a fully documented open standard and open source platform designed to connect thousands of different applications from across the financial services industry, enabling banks’ and clients’ systems to talk to each other. 

Perspective: Initially developed by JP Morgan’s trading business, Perspective is an interactive Web Assembly based data streaming and visualization component for large, real-time datasets. It comes with a suite of simple context-aware visual plugins for D3FC and Hypergrid, an integration with Jupyterlab, and runtime modules for the browser, Python, and Node.js. Perspective is a mature, production-ready library with a highly engaged community that is now increasingly used in production environments and is contributed to by FINOS institutional member organizations.

A sample Perspective application.

A sample Perspective application. Image Credit: FINOS

Alloy: Set to be contributed to FINOS by Goldman Sachs later in 2020, the Alloy workbench and the underpinning Pure language offer an advanced modeling environment to explore, define, connect and integrate data into financial business processes. Although it can help firms address internal challenges the greater benefit comes from the huge potential for the industry to share, collaborate and standardize on common data models for trading, instrumentation, regulatory reporting and more. A pilot is currently ongoing among major banks and documentation is available at alloy.finos.org.

Cloud Service Certification: Originally contributed to FINOS by JP Morgan who was working internally on building infrastructure as code controls to meet its own cloud deployment regulatory requirements, the Cloud Service Certification was created with the rationale that most banks were undergoing similar efforts — thus the benefits of mutualization could be extended to not only technology implementation, but also on regulatory interpretation, as well. The overall goal of the project is to build commonly interpreted BDD-style tests to verify regulatory compliance of cloud services for Cloud Service Providers (CSP) in order to build test implementations that can be used to prove the regulatory worthiness of cloud services on an ongoing basis. Several firms involved in the Cloud Service Certification include JP Morgan, Deutsche Bank, UBS, Red Hat, Wipro and ScottLogic, and FINOS is actively recruiting new banks and vendors to participate.

Waltz: Developed by Khartec Ltd and FINOS Platinum Member, Deutsche Bank, Waltz was created to help large organizations understand their application environment in a consistent, well-documented, easily digestible format, and to address complex enterprise architecture data organizational issues often encountered in their overall technology landscape. Waltz shows where applications reside, what they do, and how they are connected. Waltz has been used to assist with key performance metrics, data lineage, regulatory responses, and application rationalization/migration programs. 

A sample Waltz data model for a large enterprise environment

A sample Waltz data model for a large enterprise environment. Image Credit: FINOS

Why is FINOS Joining the Linux Foundation?

FINOS has grown significantly in the last two years, bringing greater awareness of open source to the financial services industry and in turn increasing the level of collaboration amongst industry participants. Joining the Linux Foundation will help FINOS accelerate this engagement even more. With common core values and highly compatible systems of governance FINOS will be able to take advantage of increased scalability and mutualization that only being part of a much larger foundation can provide, particularly through the Linux Foundation’s extensive support program offerings including but not limited to training, certification and events management. 

As with the Linux Foundation which acts as a neutral party for open source projects of all types, FINOS provides a neutral space for fintech firms to build open solutions with its projects and platforms in a neutral forum. At the Linux Foundation, FINOS will be able to continue sponsoring projects with strong disruption potential in a traditionally locked-in and proprietary industry, and will continue to permit frictionless engagement between financial services developers who are actively contributing to FINOS in full compliance. 

FINOS currently uses a governance by contribution model which enables them to be operated transparently and independently under the oversight and steering of its board of directors. This is in direct alignment with the Linux Foundation’s “do-ocracy” model where responsibilities are attached to people who do the work rather than elected or selected by some identified decision-maker. Likewise, the Linux Foundation’s projects also operate transparently and independently, and each community develops its own operational guidelines that serve to create a working technical collaboration. 

As with the Linux Foundation, FINOS has projects that are organized into thematic programs which provide easy discoverability, and federated governance over its community. 

FINOS already hosts over a hundred collaborative projects that are contributed to by its members, external companies and individuals. 

As its communities continue to scale, FINOS will need additional support staff and the abilities of an experienced, larger umbrella organization to help it achieve its goals. The toolsets and procedures, fundraising support, and overall entity management which FINOS will inherit as a result of joining the umbrella of the Linux Foundation will help them continue to scale their programmatic efforts for many years to come.

“In less than two years FINOS has become the go-to foundation for open source collaboration in financial services. With this sector’s focus on technology-driven solutions, we feel the time is right to bring our two communities together to enable the next stage of innovation for our projects,” said Jim Zemlin, executive director at the Linux Foundation. “We look forward to working with Gab, the FINOS team and its members as we together chart the future of global financial services collaboration.”

“FINOS has achieved tremendous growth across our project portfolio thanks to our 35 members and wider community,” explained Gabriele Columbro. “The FINOS community’s passion and dedication to applying open source practices to address concrete, pressing topics — in areas such as cloud computing, financial modeling, desktop interoperability, messaging, tooling, and data technology — has established the transformative potential of open source within financial services. We are thrilled to join forces with the Linux Foundation to accelerate this growth and welcome an even more diverse set of members and projects under the FINOS umbrella.”

Hyperledger Global Forum

Submit your proposal to speak at Hyperledger Global Forum.

Share your Hyperledger expertise with 1200+ users and contributors of Hyperledger projects from across the globe.

Developers, vendors and enterprise end users working on business blockchain technologies will converge in Basel this December for the inaugural Hyperledger Global Forum. Open to members and non-members alike, attendees will get to talk directly with Hyperledger project maintainers and the Technical Steering Committee, collaborate with other organizations on ideas that will directly impact the future of Hyperledger, and promote their work among the communities.

The event will feature technical and business tracks covering a range of topics and technologies including: Distributed Ledger and Smart Contracts 101; Roadmaps for Hyperledger projects; and cross-industry talks on use cases in development. Submit a talk to speak at Hyperledger Global Forum to share your expertise and learnings.

Learn more about how to submit a proposal, important dates, suggested technical and business topics, and sample submissions. Deadline to submit proposals is Friday, July 13, so apply today!

SUBMIT NOW >>

Not submitting a session, but plan to attend? Register now and save before ticket prices increase on November 26.

Sign up for updates on Hyperledger Global Forum 2018:

open source culture

Open source involves a culture of understanding change. It’s about evolution as a group, says Mesosphere’s CMO Peter Guagenti.

In the early days of open source, one of the primary goals of the open source community was educating people about the benefits of open source and why they should use it. Today, open source is ubiquitous. Almost everyone is using it. That has created a unique challenge around educating new users about the open source development model and ensuring that open source projects are sustainable.

Peter Guagenti, CMO at Mesosphere, Inc.

Peter Guagenti, the Chief Marketing Officer at Mesosphere, Inc., has comprehensive experience with how open source works, having been involved with several leading open source projects. He has been a coder, but says that he considers himself a hustler. We talked with him about his role at Mesosphere, how to help companies become good open source citizens, and about the role of culture in open source. Here is an edited version of that interview.

The Linux Foundation: What’s the role of a CMO in an open source software company?

Peter Guagenti: The role of a CMO in a software company is fundamentally different from that in any other category.  We have a really interesting role in marketing and technology, and it’s one of education and guidance. There used to be a place 20 years ago where, as a marketer, you would come up with a simple pithy message and buy a bunch of advertising and people would believe it.

That’s not true anymore. Now we have to position ourselves alongside the architectures and the thought leadership that our customers are interested in to prove our value.

The Linux Foundation: Can you explain more about this approach?

Guagenti: I love that instead of focusing on marketing taglines, you really have to know the technology so customers have the confidence that they will get the support we promise. Since this space is changing so quickly, we spend probably half our time simply on educating and informing about the market and the challenges that customers face.

I don’t think about talking about DCOS, for example; I think about how connected cars are really important but nobody really knows how to build them. We serve six of the largest car makers in the world. So getting them to talk about how they’re approaching this problem — what they think about Edge computing, what they think about computing in the car, or what they think about data and moving that data around. These are the real exciting things.

The Linux Foundation: Can you talk about other work you have done in open source?

Guagenti:  I’m a long-time open source advocate. I’ve been in open source for over 10 years. I built an open source services practice in a large digital agency called Razorfish when I was at a client services there. I’ve spent time at three open source companies: Acquia, which is in the Drupal open source project; Nginx, which is the world’s most popular web server and application delivery controller; and now I am at Mesosphere, the container company.

The Linux Foundation: Open source has become the de facto software development model — almost everyone is consuming open source these days. That creates a new challenge as many new consumers don’t fully understand how open source works, which can lead to problems like not being part of the ecosystem and creating technical debt. Have you come across this problem?

Guagenti: Open source has evolved dramatically over the past 20 years. I would argue 10 years ago you were crazy if you were a Fortune 500 company and you were the CIO and said I’m going to integrate open source everywhere. But now open source is the default. I’ve worked in large state and national governments around the world. I’ve worked in the Fortune 500, and they all have adopted open source. But how they adopt open source successfully is different. If you look company by company, if you look at projects, there is a difference.

There are community-driven models, there are corporate-driven models, and there are things in between where you see things like Kubernetes, where you’ve multiple companies contributing at scale. There is a great mix, but companies don’t always know how to make the best use of that. It becomes critical for them to find the right enterprise that helps them understand how to use and deploy it. More important than that is to help them ensure they are making good decisions with that software and driving the roadmap forward by contributing or at least by being a voice in that.

We take for granted that open source exists, but open source requires involvement—either contribution of code or cash—to keep those projects healthy. We are at a point where open source has been around long enough that we have seen early open source projects just die because they didn’t have core maintainers able to earn a salary.

I was told that every great technology company needs a hacker and a hustler. I was a good coder early on, but I wasn’t great. I’m more of a hustler. I loved being able to see businesses build around open source and then have have that really be the heart of a healthy ecosystem where everyone is able to benefit from that code.

The Linux Foundation: What role does culture play in open source adoption?

Guagenti: It matters. Look at the digital transformation that we have been going through for the last 20 years. Look at the companies that have done it best. You will notice that the old stalwarts have now reinvented themselves in a meaningful way. They are continuing to evolve with the time and are competing effectively. They had a culture where they could embrace and accept a lot of these things.  

If you look at hiring the great technology talent, what’s the number one thing great technology talent expects? They want to work with the tools they want to use. They want to do it in a way that fits their pattern of behavior, their pattern of building these things. It’s not the money, it’s not the stock options, it’s not the fancy work. It’s about the kind of work I want to do everyday and and the way I want to do it.  

I work with some of the largest banks, I work with some of the largest government entities. What I have noticed, with some of the most successful ones, is that they have a culture internally where they understand this stuff. They understand what it means to not just use open source but to be a part of an open source community. Sometimes you do run into hurdles. I work with a lot of large companies that are either not comfortable contributing code back or just simply don’t feel they have the time to do it. But they do their bit in a different way; they may do things like contribute  financially to projects, send people to to events, or actually go and tell their story.

That’s what we do a lot at Mesosphere. Since this space is changing, we love having our largest customers talking about what they’re doing with open source. Their culture matters because it’s not just the culture of open source and using open source. It’s a culture of innovation. It’s a culture of understanding change.  And that’s what open source is all about. It’s about evolution as a group.

Learn more about best practices for sustainable open source in the free Open Source Guides for the Enterprise from The Linux Foundation.

A guest blog post by Mike Goodwin.

What is threat modeling?

Application threat modeling is a structured approach to identifying ways that an adversary might try to attack an application and then designing mitigations to prevent, detect or reduce the impact of those attacks. The description of an application’s threat model is identified as one of the criteria for the Linux CII Best Practises Silver badge.

Why threat modeling?

It is well established that defense-in-depth is a key principle for network security and the same is true for application security. But although most application developers will intuitively understand this as a concept, it can be hard to put it into practice. After many years and sleepless nights, worrying and fretting about application security, one thing I have learned is that threat modeling is an exceptionally powerful technique for building defense-in-depth into an application design. This is what first attracted me to threat modeling. It is also great for identifying security flaws at design time where they are cheap and easy to correct. These kinds of flaws are often subtle and hard to detect by traditional testing approaches, especially if they are buried in the innards of your application.

Three stages of threat modeling

There are several ways of doing threat modeling ranging from formal methodologies with nice acronyms (e.g. PASTA) through card games (e.g. OWASP Cornucopia) to informal whiteboard sessions. Generally though, the technique has three core stages:

Decompose your application – This is almost always done using some kind of diagram. I have seen successful threat modeling done using many types of diagrams from UML sequence diagrams to informal architecture sketches. Whatever format you choose, it is important that the diagram shows how different internal components of your application and external users/systems interact to deliver its functionality. My preferred type of diagram is a Data Flow Diagram with trust boundaries:

Identify threats – In this stage, the threat modeling team ask questions about the component parts of the application and (very importantly) the interactions or data flows between them to guess how someone might try to attack it. The answers to these questions are the threats. Typical questions and resulting threats are:

Question Threat
What assumptions is this process making about incoming data? What if they are wrong? An attacker could send a request pretending to be another person and access that person’s data.
What could an attacker do to this message queue? An attacker could place a poison message on the queue causing the receiving process to crash.
Where might an attacker tamper with the data in the application? An attacker could modify an account number in the database to divert payment to their own account.

Design mitigations – Once some threats have been identified the team designs ways to block, avoid or minimize the threats. Some threats may have more than one mitigation. Some mitigations might be preventative and some might be detective. The team could choose to accept some low-risk threats without mitigations. Of course, some mitigations imply design changes, so the threat model diagram might have to be revisited.

Threat Mitigation
An attacker could send a request pretending to be another person and access that person’s data. Identify the requestor using a session cookie and apply authorization logic.
An attacker could place a poison message on the queue causing the receiving process to crash. Digitally sign message on the queue and validate their signature before processing.
Maintain a retry count on message and discard them after three retries.
An attacker could modify an account number in the database to divert payment to their own account. Preventative: Restrict access to the database using a firewall.
Detective: Log all changes to bank account numbers and audit the changes.

OWASP Threat Dragon

Threat modeling can be usefully done with a pen, whiteboard and one or more security-aware people who understand how their application is built, and this is MUCH better than not threat modeling at all. However, to do it effectively with multiple people and multiple project iterations you need a tool. Commercial tools are available, and Microsoft provides a free tool for Windows only, but established, free, open-source, cross-platform tools are non-existent. OWASP Threat Dragon aims to fill this gap. The aims of the project are:

  • Great UX – Using Threat Dragon should be simple, engaging and fun
  • A powerful threat/mitigation rule engine – This will lower the barrier to entry for teams and encourage non-specialists to contribute
  • Integration with other development lifecycle tools – This will ensure that models slot easily into the developer workflows and remain relevant as the project evolves
  • To always be free, open-source (like all OWASP projects) and cross-platform. The full source code is available on GitHub

The tool comes in two variants:

End-user documentation is available for both variants and, most importantly, it has a cute logo called Cupcakes…

Threat Dragon is an OWASP Incubator Project – so it is still early stage but it can already support effective threat modeling. The near-term roadmap for the tool is to:

  • Achieve a Linux CII Best Practices badge for the project
  • Implement the threat/mitigation rule engine
  • Continue to evolve the usability of the tool based on real-world feedback from users
  • Establish a sustainable hosting model for the web application

If you want to harden your application designs you should definitely give threat modeling a try. If you want a tool to help you, try OWASP Threat Dragon! All feedback, comments, issue reports and pull requests are very welcome.

About the author: Mike Goodwin is a full-time security professional at the Sage Group where he leads the team responsible for product security. Most of his spare time is spent working on Threat Dragon or co-leading his local OWASP chapter.

This article originally appeared on the Core Infrastructure Initiative website.

OS Summit keynotes

Watch keynotes and technical sessions from OS Summit and ELC Europe here.If you weren’t able to attend Open Source Summit and Embedded Linux Conference (ELC) Europe last week, don’t worry! We’ve recorded keynote presentations from both events and all the technical sessions from ELC Europe to share with you here.

Check out the on-stage conversation with Linus Torvalds and VMware’s Dirk Hohndel, opening remarks from The Linux Foundation’s Executive Director Jim Zemlin, and a special presentation from 11-year-old CyberShaolin founder Reuben Paul. You can watch these and other ELC and OS Summit keynotes below for insight into open source collaboration, community and technical expertise on containers, cloud computing, embedded Linux, Linux kernel, networking, and much more.

And, you can watch all 55+ technical sessions from Embedded Linux Conference here.

documentation

At the upcoming APIStrat conference in Portland, Taylor Barnett will explore various documentation design principles and discuss best practices.

Taylor Barnett, a Community Engineer at Keen IO, says practice and constant iteration are key to writing good documentation.  At the upcoming API Strategy & Practice Conference 2017, Oct. 31 -Nov. 2 in Portland, OR, Barnett will explain the different types of docs and describe some best practices.

In her talk — Things I Wish People Told Me About Writing Docs — Barnett will look at how people consume documentation and discuss tools and tactics to enable other team members to write documentation.  Barnett explains more in this edited interview.

The Linux Foundation: What led you to this talk? Have you encountered projects with bad documentation?

Taylor Barnett: For the last year, my teammate, Maggie Jan, and I have been leading work to improve the developer content and documentation experience at Keen IO. It’s no secret that developers love excellent documentation, but many API companies aren’t always equipped with the resources to make that happen. As a result of this, we all come across a lot of bad documentation when you are trying to use developer tools and APIs.

The Linux Foundation: Often, there is a team of documentation writers and there are developers who wrote that piece of software; both are experts in their own fields, but they need a lot of collaboration to create usable docs. How can that collaboration be improved?

Barnett: In large companies, this can definitely be true, although in many companies documentation is still owned by various teams. The need for more collaboration still applies, though. One way to improve collaboration is bringing docs into the product development process early on. If you wait until everything is done and going to be released soon, people writing documentation are going to feel left out of the process and like an afterthought. If people working on the product development collaborate early on, not only does the product become better, but so does the documentation. People who are writing documentation usually spend some time figuring out the API or tool they are writing about, so they only get better when they can work with the people doing product development early on. Also, they can give great feedback from a user’s perspective much earlier in the process.

Another way to improve collaboration is to bring more people into the documentation review process. We do most of our documentation reviews in GitHub. It’s great to not only have someone in the role of an editor review it but also people from the Engineering or Product teams. It increases the number of eyes on the docs and helps make them better.

The Linux Foundation: How should developers approach documentation?

Barnett: Most developers are pretty familiar with the idea of Test Driven Development (TDD), but how familiar are they with Documentation Driven Development (DDD)? The flow for DDD is:

  1. Write or update documentation,
  2. Get feedback on that documentation,
  3. Write a failing test according to that documentation (TDD),
  4. Write code to pass the failing test,
  5. Repeat.

It can be an excellent way for developers to save a lot of time and prevent spending too much time on poorly designed features. As Isaac Schlueter, co-founder of npm, says about Documentation Driven Development, writing clear prose is an “effective way to increase productivity by reducing both the frequency and cost of mistakes.” Our brains can only hold so much information at once. In computer terms, our working memory size is pretty small. Writing down some of the information we are thinking about is a way to “off-load significant chunks of thought with hardly any data-loss,” while allowing us to think slower and more carefully.

For example: At Keen IO, we recently split our JavaScript library into three different modules. This decision was inspired by the documentation we were maintaining. We had tried to streamline the docs, but there was just too much to cover in an attention-constrained world. Many important details and features were hidden in the noise. For example, if all of the documentation was written sooner, we may have made this decision sooner.

Also, as a developer who is writing docs myself, constant iteration and practice are important. Your first version of the docs aren’t going to be great, but with focusing on trying to write clear prose, they will get better with time. Also, having another person who is not familiar with the product and can step through the documentation to review it is essential.

The Linux Foundation: If developers are writing documentation for other developers, how can they really think as the users?

Barnett: I used to think that developers are the best people to write docs for other developers because they are one of them. While I still believe this is partially true, some developers also assume a lot of knowledge. If it has been a while since a developer has done something, the “curse of knowledge” can exist. The more you know, the more you forget what it was like before. That’s why I like to talk about empathic documentation.

You need to empathize with the user on the other end. Don’t assume they know how to do something and give resources to fill in the steps that might seem “easy” to you. Also, hearing that something is “easy” or “simple” when something is not working on the user’s’ end is the worst feeling. It makes your users doubt themselves, feel frustrated, and a bunch of other negative emotions. Always try to remember you need to be empathetic!

The Linux Foundation: What’s the importance of tools in creating documentation?

Barnett: Very important! Earlier I mentioned using GitHub for reviews. I also would recommend having some continuous integration testing in place for your documentation site if you aren’t using a service like ReadMe or Apiary to make sure you don’t break it. A related topic is, do you build your own thing or use a service? Tools can be helpful, but they might not always be the best fit. You have to find a balance based on your current resources. Lastly, I would recommend checking out Anne Gentle’s book, Docs Like Code. She brings up tools a lot in the book.

The Linux Foundation: Who should attend your session?

Barnett: Everyone! Just kidding (kind of). If you are in any role that is developer facing like developer relations, evangelists, advocates, marketers, etc., if you are on a Product team for a developer focused product or platform, or if you are a developer or engineer who wants to write better docs.

The Linux Foundation: What is the main takeaway from your talk?

Barnett: Anyone can write docs, but with some practice, iteration, and working on different documentation writing skills anyone can write better docs.

Learn more in Taylor Barnett’s talk at the APIStrat conference coming up Oct. 31 – Nov. 2 in Portland, Oregon.

APIs

Learn tricks, shortcuts, and key lessons learned in creating a Developer Experience team, at APIStrat.

Many companies that provide an API also include SDKs. At SendGrid, such SDKs send several billions of emails monthly through SendGrid’s Web API. Recently, SendGrid re-built their seven open source SDKs (Python, PHP, C#, Ruby, Node.js, Java, and Go) to support 233 API endpoints, a process which I’ll describe in my upcoming talk at APIStrat in Portland.

Fortunately, when we started this undertaking, Matt Bernier had just launched our Developer Experience team, covering our open source documentation and libraries. I joined the team as the first Developer Experience Engineer, with a charter to manage the open source libraries in order to ensure a fast and painless integration with every API SendGrid produces.

Our first task on the Developer Engineering side was to update all of the core SendGrid SDKs, across all seven programming languages, to support the newly released third version of the SendGrid Web API and its hundreds of endpoints. At the time, our SDKs only supported the email sending endpoint for version 2 of the API, so this was a major task for one person. Based on our velocity, we calculated that it would take about 8 years to hand code every single endpoint into each library.

This effort involved automated integration test creation and execution with a Swagger/OAI powered mock API server, documentation, code, examples, CLAs, backlogs, and sending out swag. Along the way, we also gained some insights on what should not be automated — like HTTP clients.

In my talk at APIStrat, I am going to share some tricks, automations, shortcuts, and key lessons that I learned on our journey to creating a Developer Experience team:

  • We will walk through what we automated and why, including how we leveraged OpenAPI and StopLight.io to automate SDK documentation, code, examples, and tests.
  • Then we’ll dive into how we used CLA-Assistant.io to automate CLA signing and management along with Kotis’ API to automate sending and managing swag for our contributors.
  • We’ll explore how these changes were received by our community, how we adapted to their feedback and prioritized with the RICE framework.

If you’re interested in attending, please take a moment to register and sign up for my talk. I hope to see you there!

OpenStack Summit Sydney

OpenStack Summit Sydney offers 11+ session tracks and plenty of educational workshops, tutorials, panels. Start planning your schedule now.

Going to OpenStack Summit Sydney? While you’re there, be sure stop by The Linux Foundation training booth for fun giveaways and a chance to win a Raspberry Pi kit. The drawing for prizes will take place 1 week after the conference on November 15.

Giveaways include The Linux Foundation projects’ stickers, and free ebooks: The SysAdmin’s Essential Guide to Linux Workstation Security, Practical GPL Compliance, A Guide to Understanding OPNFV & NFV, and the Open Source Guide Volume 1.

With 11+ session tracks to choose from, and plenty of educational workshops, tutorials, panels — start planning your schedule at OpenStack Summit in Sydney now.

Session tracks include:

  • Architecture & Operations
  • Birds of a Feather
  • Cloud & OpenStack 101
  • Community & Leadership
  • Containers & Cloud-Native Apps
  • Contribution & Upstream Development
  • Enterprise
  • Forum
  • Government
  • Hands-on Workshop
  • Open Source Days
  • And More.

View the full OpenStack Summit Sydney schedule here.

Cloud Native Computing Foundation and Cloud Foundry will also have a booth at OpenStack Summit Sydney. Get your pass to OpenStack and stop by to learn more!

 

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.