Posts

 

All Things Open

Join The Linux Foundation at All Things Open; check out conference highlights below. (Image: All Things Open)

Going to All Things Open in Raleigh? While you’re there, be sure stop by The Linux Foundation training booth for fun giveaways and a chance to win one of two Raspberry Pi kits. Two winners will be chosen onsite on the last day of the conference, Oct. 24, at 3:05pm.

Other booth giveaways include The Linux Foundation branded webcam covers, The Linux Foundation projects’ stickers, Tux stickers, Linux.com stickers, as well as 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.

Be sure to check out these featured conference talks, including the Linux on the Mainframe session where John Mertic and Len Santalucia discuss how they’ve worked to create an open source, technical community where industry participants can collaborate around the use of the Linux and open source in a mainframe computing environment. And don’t miss ODPi’s session on the simplification and standardization of the Big Data ecosystem with common reference specifications and test suites.

Session Highlights

  • Accelerating Big Data Implementations For the Connected World – John Mertic
  • Advancing the Next-Generation Open Networking Stack – Phil Robb
  • Flatpak: The Portable, Secure Distribution of Desktop ApplicationsOwen Taylor
  • Intel: Core Linux Enabling Case Study and Demo
  • Integrating Linux Systems With Active Directory Using Open Source Tools – Dmitri Pal
  • Linux On the Mainframe: Linux Foundation and The Open Mainframe Project – John Mertic & Len Santalucia
  • Polyglot System Administration AKA: Don’t Fear the Other Language – Jakob Lorberblatt
  • The Next Evolution of The Javascript Ecosystem – Kris Borchers
  • The Revolution Will Not Be Distributed – Michael Hall
  • You Think You’re Not A Target? A Tale Of Three Developers – Chris Lamb

ODPi and Open Mainframe will also a have booth at All Things Open. Get your pass to All Things Open and stop by to learn more!

 

Open Source Summit EU

Going to Open Source Summit? Check out some featured conference presentations and activities below.

Going to Open Source Summit EU in Prague? While you’re there, be sure stop by The Linux Foundation training booth for fun giveaways and a chance to win one of three Raspberry Pi kits.

Giveaways include The Linux Foundation branded webcam covers, The Linux Foundation projects’ stickers, Tux stickers, Linux.com stickers, as well as free ebooks: The SysAdmin’s Essential Guide to Linux Workstation Security, Practical GPL Compliance, and A Guide to Understanding OPNFV & NFV.

You can also enter the raffle for a chance to win a Raspberry Pi Kit. There will be 3 raffle winners: names will be drawn and prizes will be mailed on Nov. 2.

And, be sure to check out some featured conference presentations below, including how to deploy Kubernetes native applications, deploying and scaling microservices, opportunities for inclusion and collaboration, and how to build your open source career.

Session Highlights

  • Love What You Do, Everyday! – Zaheda Bhorat, Amazon Web Services
  • Detecting Performance Regressions In The Linux Kernel – Jan Kara, SUSE
  • Highway to Helm: Deploying Kubernetes Native Applications – Michelle Noorali, Microsoft
  • Deploying and Scaling Microservices with Docker and Kubernetes – Jérôme Petazzoni, Docker
  • printk() – The Most Useful Tool is Now Showing its Age – Steven Rostedt, VMWare
  • Every Day Opportunities for Inclusion and Collaboration – Nithya Ruff, Comcast

Activities

  • Technical Showcase
  • Real-Time Summit
  • Free Day with Prague tour from local students
  • KVM Forum
  • FOSSology – Hands On Training
  • Tracing Summit

The Cloud Native Computing Foundation will also a have booth at OSSEU. Get your pass to Open Source Summit Europe and stop by to learn more! Use discount OSSEULFM20 code for 20% off your all-access attendee pass.

Check out the full list of co-located events on the website and register now.

API

Learn the basics of using REST APIs at the upcoming APIStrat conference.

APIs are becoming a very popular and are a must-know for every type of developer. But, what is an API? API stands for Application Programming Interface. It is a way to get one software application to talk to another software application. In this article, I’ll go over the basics of what they are and why to use them.

Nom Nom Nom! I happened to be snacking on chips while trying to think of a name for my REST API talk coming up at APIStrat in Portland. Similarly, the act of consuming or using a REST API means to eat it all up. In context, it means to eat it, swallow it, and digest it — leaving any others in the pile exposed. Sounds yummy, right?

It seems that every application out there is hungry for an API. Let’s look at Yelp for example. Yelp by itself won’t have the functionality you’d expect. In order to search nearby restaurants or locations, it needs to use an API for a map. It uses the Google API. With that, you can locate nearest places and get directions to the place. APIs allow you to integrate one tool into another tool to give it more functionality. Without the ability to make these types of integrations, you can say goodbye to a majority of all the apps out there that you use!

So why are APIs so important? Most companies today have several different software applications they need to use, including sales, accounting, CRM, a project management system, etc. To have the software all work together is increasingly important for financial reasons, which is also making work processes flow more easily. Companies can also create their own tools using other APIs to enhance their own software, making their customers happier and giving them the tools they need.

API Basics

Back in 2000, the very first API came from eBay. Since then, they have increased exponentially. In 2016, more than 50 million API requests have been made, and there are 30,000 available APIs out there. From 2015 to 2016, the number has doubled in growth from 15,000 to 30,000 APIs!

In my talk, I will be covering API basics, how to make API requests, how APIs are made, and much more.  I will show you how you can use POSTMAN to test making REST API calls, so that you will leave with the skills to make REST calls on any API. This talk is designed for any audience level. If you are brand new to programming, that’s fine. If you are an experienced programmer that currently uses APIs but want to go back into the basics to understand the breakdown of how APIs work, then that is fine, too!

If you want to learn more, be sure to check out my other talk at APIStrat:  “Chatbots are the Future: Let’s Build One!” In this talk, I will go over how to build a working Chatbot using the Cisco Spark API, which is a collaboration API for chat (messages), calling, and video. You don’t need to install or download anything to prepare. I will cover everything in the presentation, and it is designed for everyone to follow along. I guarantee you will have a working chatbot by the end of the presentation.

You can learn more at the upcoming APIStrat conference

Testing is especially important in modern distributed software systems. Learn more at the upcoming APIStrat conference.

As developers, we often hear that tests are important. Automated testing minimizes the number of bugs released to production, helps prevent regression, improves code quality, supplements documentation, and makes code reviews easier. In short, tests save businesses money by increasing system uptime and keeping developers working on new features instead of fighting fires. While software testing has been around for about as long as software has, I would argue that testing is especially important (and unfortunately more challenging) in modern distributed software systems.

Distributed software” refers to any software that is not run entirely on one computer. Almost all web applications are distributed software as they rely on applications on other servers (eg: remote data stores, internal REST APIs, third-party APIs, content delivery networks, etc.), and most mobile and desktop applications are as well. Distributed software presents new challenges and requires a thoughtful approach to testing. This list includes just some of the reasons that testing is crucial for distributed software:

1. Third Party APIs Can Change Unexpectedly

We would like to think that every REST API we use will adhere to some form of versioning, but this doesn’t always happen. Sometimes APIs break when a maintainer fixes a bug, sometimes breaking changes are overlooked, and sometimes the API just isn’t mature or stable yet. With more companies releasing public APIs, we’re bound to see the number of accidentally breaking releases rise, and tests are a great way to prevent those breaking changes from affecting our applications.

2. Internal API Changes can Affect Your App in Unexpected Ways

Even more commonly, breaking API changes come from within our own organization. For the past few years, I’ve been working with startups where the business requirements change almost as fast as we can implement them, so our internal APIs are rarely stable and sometimes the documentation gets outdated. Slowing down, improving communication between team-members, and writing tests for our internal APIs has helped.

3. Remotely Distributed Open Source Packages are More Popular Than Ever

78% of companies are now running on some form of open source software. This has helped the speed and ease of developing software to increase exponentially, but blindly relying on open source packages has bitten plenty of developers as well (see the left-pad incident of 2016). Once again, we hope that open source packages use semantic versioning, but it’s impossible to guarantee this. Testing the boundaries between packages and our software is one way to help improve reliability.

4. Network Connections Aren’t Perfect

In many server-to-server cases, network connections are pretty reliable, but when you start serving up data to a browser or mobile client via an API, it gets much harder to guarantee a connection. In either case, you should have a plan for failure: Does your app break? Throw an error? Retry gracefully? Adding tests that simulate a bad network connection can be a huge help in minimizing poor user experiences or data loss.

5. Siloed Teams can Lead to Communication Gaps

One of the advantages to distributed systems is that a team can be assigned to each component. This allows each team to become an expert on just one part of the system, enabling the scaling of software organizations like we see at Amazon. The downside to these siloed teams is that communication becomes more difficult, but a good test suite, thorough documentation, and self-documenting APIs can help minimize these gaps.

How Do We Test Distributed Systems?

Distributed software has become more popular as the cost of cloud computing has gone down and network connections have become more reliable. While distributed systems offer unique advantages for scaling and cost savings, they introduce new challenges for testing.

Borrowing from some of Martin Fowler’s ideas on testing microservices and my own experience building layered test plans, I’ll be presenting a strategy for testing distributed systems at this year’s API Strategy & Practice Conference. If you’re interested in learning more about the topic of testing distributed software, or you have questions, you can find me at the conference, or anytime on Twitter.

Learn more at APIStrategy and Practice Conference.

Join the Apache Mesos community in Prague for town halls, MesosCon university, and a full-day hackathon.

Get the latest on Apache Mesos with Ben Hindman, Co-Creator of Apache Mesos, at MesosCon Europe taking place October 25-27, 2017 in Prague, Czech Republic. At the conference, you’ll hear insights by industry experts deploying Mesos clusters, learn about containerization and security in Mesos, and more.

This annual conference brings together users and developers to share and learn about the Mesos project and its growing ecosystem. The conference features two days of sessions focused on the Apache Mesos Core and related technologies, as well as a one-day hackathon, town halls, and MesosCon University.  

Highlights include:

  • SMACK in the Enterprise keynote panel: Hear how the SMACK stack is impacting the data analytics landscape at large enterprises. Panelists will be announced soon.
  • MesosCon University: Tutorial-style sessions will offer hands-on learning for building a stateful service, operating your cluster, or bootstrapping a secure Mesos cluster.
  • Town Halls: A community gathering to discuss pressing needs and issues. The town halls will begin at 7:00pm after the onsite reception on Thursday, and will include drinks and appetizers sponsored by Mesosphere. Have a town hall you think we should run? Reach out to events@linuxfoundation.org.
  • Hackathon: Come and work on new Mesos features, new demos, new documentation, and win great prizes! The Hackathon will take place on Wednesday, October 25, and is included with your conference registration.  

View the full schedule of sessions and activities here.

Get a preview of what to expect at MesosCon Europe. Watch videos from MesosCon North America 2017 here.

Register now and use discount code MCEULDC17 to save $25 off your pass to MesosCon Europe.

Through a collaborative effort from enterprises and communities invested in cloud, big data, and standard APIs, I’m excited to welcome the OpenMessaging project to The Linux Foundation. The OpenMessaging community’s goal is to create a globally adopted, vendor-neutral, and open standard for distributed messaging that can be deployed in cloud, on-premise, and hybrid use cases.

Alibaba, Yahoo!, Didi, and Streamlio are the founding project contributors. The Linux Foundation has worked with the initial project community to establish a governance model and structure for the long-term benefit of the ecosystem working on a messaging API standard.

As more companies and developers move toward cloud native applications, challenges are developing at scale with messaging and streaming applications. These include interoperability issues between platforms, lack of compatibility between wire-level protocols and a lack of standard benchmarking across systems.

In particular, when data transfers across different messaging and streaming platforms, compatibility problems arise, meaning additional work and maintenance cost. Existing solutions lack standardized guidelines for load balance, fault tolerance, administration, security, and streaming features. Current systems don’t satisfy the needs of modern cloud-oriented messaging and streaming applications. This can lead to redundant work for developers and makes it difficult or impossible to meet cutting-edge business demands around IoT, edge computing, smart cities, and more.

Contributors to OpenMessaging are looking to improve distributed messaging by:

  • Creating a global, cloud-oriented, vendor-neutral industry standard for distributed messaging
  • Facilitating a standard benchmark for testing applications
  • Enabling platform independence
  • Targeting cloud data streaming and messaging requirements with scalability, flexibility, isolation, and security built in
  • Fostering a growing community of contributing developers

You can learn more about the new project and how to participate here: http://openmessaging.cloud

These are some of the organizations supporting OpenMessaging:

“We have focused on the messaging and streaming field for years, during which we explored Corba notification, JMS and other standards to try to solve our stickiest business requirements. After evaluating the available alternatives, Alibaba chose to create a new cloud-oriented messaging standard, OpenMessaging, which is a vendor-neutral and language-independent and provides industrial guidelines for areas like finance, e-commerce, IoT, and big data. Moreover, it aims to develop messaging and streaming applications across heterogeneous systems and platforms. We hope it can be open, simple, scalable, and interoperable. In addition, we want to build an ecosystem according to this standard, such as benchmark, computation, and various connectors. We would like to have new contributions and hope everyone can work together to push the OpenMessaging standard forward.” — Von Gosling, senior architect at Alibaba, co-creator of Apache RocketMQ, and original initiator of OpenMessaging

“As the sophistication and scale of applications’ messaging needs continue to grow, lack of a standard interface has created complexity and inflexibility barriers for developers and organizations. Streamlio is excited to work with other leaders to launch the OpenMessaging standards initiative in order to give customers easy access to high-performance, low-latency messaging solutions like Apache Pulsar that offer the durability, consistency, and availability that organizations require.” — Matteo Merli, software engineer at Streamlio, co-creator of Apache Pulsar, and member of Apache BookKeeper PMC

“Oath–a Verizon subsidiary of leading media and tech brands including Yahoo and AOL– supports open, collaborative initiatives and is glad to join the OpenMessaging project.” Joe Francis, director, Core Platforms

“In Didi, we have defined a private set of producer API and consumer API to hide differences among open source MQs such as Apache Kafka, Apache RocketMQ, etc. as well as to provide additional customized features. We are planning to release these to the open source community. So far, we have accumulated a lot of experience on MQs and API unification, and are willing to work in OpenMessaging to construct a common standard of APIs together with others. We sincerely believe that a unified and widely accepted API standard can benefit MQ technology and applications that rely on it.” — Neil Qi, architect at Didi

“There are many different open source messaging solutions, including Apache ActiveMQ, Apache RocketMQ, Apache Pulsar, and Apache Kafka. The lack of an industry-wide, scalable messaging standard makes evaluating a suitable solution difficult. We are excited to support the joint effort from multiple open source projects working together to define a scalable, open messaging specification. Apache BookKeeper has been successfully deployed in production at Yahoo (via Apache Pulsar) and Twitter (via Apache DistributedLog) as their durable, high-performance, low-latency storage foundation for their enterprise-grade messaging systems. We are excited to join the OpenMessaging effort to help other projects address common problems like low-latency durability, consistency and availability in messaging solutions.” — Sijie Guo, co-founder of Streamlio, PMC chair of Apache BookKeeper, and co-creator of Apache DistributedLog

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

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

Reuben Paul, co-founder of CyberShaolin

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

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

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

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

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

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

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

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

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

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

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

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

Improve the efficiency of your software development team with the RICE framework. Learn more at the upcoming APIStrat conference in Portland, Oregon.

The Developer Experience team at SendGrid is a small, but mighty force of two. We attempt to tackle every problem that we can get our hands on. This often means that some items get left behind.  At the outset, we surveyed everything that was going on in our open source libraries and we quickly realized that we needed to find a way to prioritize what we were going to work on. Luckily, our team lives, organizationally, on the Product Management team, and we had just received a gentle nudge and training on the RICE prioritization framework.

On our company blog, I wrote an article about how employing this framework, using a spreadsheet, helped us double our velocity as a team within the first sprint. Our development velocity doubled because the most impactful things for the time spent are not always the biggest things, but the biggest things tend to attract the most attention due to their size.

What is RICE?

RICE as an acronym stands for Reach x Impact x Confidence, all divided by Effort. This calculation allows you to get a score that weighs the following. Some of the definitions we use are a slight departure from Intercom’s original version, but this has been very effective for us!

The calculation:

Reach * Impact * Confidence

————————————–

               Effort

This gives us a score for every item in our list. Then, we sort our list in descending order by score. We realized, once we had a sorted list, that we accidentally made a Kanban backlog. We worked from the top of the list, keeping work in progress (WIP) to as much of a minimum as possible. WIP can be tough with open source, because we often have 20-30 issues waiting for a community member response. These items sit at the top of our backlog, and we look into them at the start of every day in the hope that we can clear them out of our WIP category.

Lessons Learned

Reach – The number of customers this will affect

One thing we learned about using RICE is making sure that we use consistent numbers for each of the variables in the calculation. It was very tempting for us, an email company, to use the “number of emails” sent as the Reach parameter. This worked until we started trying to evaluate tasks that didn’t have anything to do with our v3/mail/send endpoint. We eventually settled on number of customers using this library for this purpose”, calculating API user count and mail user count for the Reach.

Impact – A measure of the effect completing this project will have

It is easy to assume that every single item is a high or massive priority. It looks nice, gives you an ego boost, and totally messes up everything in your ranking system. Be honest with yourself about what is on your list. If things don’t really seem to be in the right place in your list (more on this below) then look at impact, because it’s probably artificially high, especially in context of the items around it in the list.

Confidence – How confident are we that we can sit down and complete this task today

We use a text-based selection from the list: None, Minimal, Low, Medium, High, and “with my eyes closed”.  These each translate into specific numbers for the calculation.

Effort – The number of story points will this take to complete

We use story points because this approach allows us to figure out the calendar length of a task rather than the aggregate of specific amounts of time spent on the task. To be more specific, this is the difference between “It’s going to take 3 hours” and “It will only take 3 hours of work, but it won’t be finished until Friday.” This is an easy trap to fall into, because new projects are exciting and we want to jump in and knock them out. That doesn’t mean that we can actually get a project that “will only take a couple days” done within the same month we started it. Life happens, your velocity calculation accounts for that — especially if you use an average over the last year (get out yer agile pitchforks!).

Letting the backlog win

We have learned the hard way with projects we really want to work on right now, that they are not always the right project at the moment. It is important to have confidence in the calculation and take the assumption that it is correct. That is, until you are looking at the list and realize that “Hey, item 15 really should be item 5. What’s going on here?” Look at your list in context of the other items, does the order feel correct? If not, why not?

We ended up using RICE as the baseline calculation for everything we do, but it is not the end-all. We added in calculation modifiers for company priority, due dates, and status — because something the executives have on the company roadmap, that has to be done in Q3, should be worked on right away. And, because we are using Kanban, the status of an item is important. Once you start something, it should stay at the top of the list until it is done, or you decide it is no longer necessary to complete it. Getting WIP completed, rather than backed up, is a good way to see the impact of your work and get a sense of accomplishment for yourself and your development team.

Matt Bernier is the Developer Experience Product Manager at SendGrid, where he spends most of his time digging into customer feedback in order to provide a World Class Experience for Developers with SendGrid.

Learn more in Matt Bernier’s talk — How We Doubled the Velocity of Our Developer Experience Team — at the APIStrat conference coming up Oct. 31 to Nov. 2 in Portland, Oregon.

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

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

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

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

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

Categorized Tools

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

Do you know how to answer questions like these?

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

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

Methodologies

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

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

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

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

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

At Open Source Summit in Prague, Giovanni Bechis will discuss tools that improve software security by blocking unwanted syscalls.

At the upcoming Open Source Summit Europe + ELC Europe 2017, to be held in Prague, Czech Republic, Giovanni Bechis will be delivering a talk focused on tools that help improve software security by blocking unwanted syscalls.  

Giovanni Bechis

Bechis is CEO and DevOps engineer at SNB s.r.l., a hosting provider and develops web applications based on Linux/BSD operating systems that is mainly focused on integrating web applications with legacy softwares. In this interview, Bechis explained more about his approach to software security.

Linux.com: What’s the focus of your talk?

Giovanni Bechis: The talk will focus on two similar solutions implemented in Linux and OpenBSD kernels, designed to prevent a program from calling syscalls they should not call to improve security of software.

In both kernels (Linux and OpenBSD), unwanted syscalls can be blocked and the offending program terminated, but there are some differences between Linux and OpenBSD’s solution of the problem.

During my talk, I will analyze the differences between two similar techniques that are present in Linux and OpenBSD kernels that are used to mitigate security bugs (that could be used to attack  software and escalate privileges on a machine).

Linux.com: Who should attend?

Bechis: The scope of the talk is to teach developers how they can develop better and more secure software by adding just few lines to their code. The target audience is mainly developers interested in securing applications.

Linux.com: Can you please explain both solutions and what problems they actually solve?

Bechis: The main problem that these solutions are trying to solve is that bugs can be exploited to let software do something that it is not designed to do. For example, with some crafty parameters or some crafty TCP/IP packet, it could be possible to let a program read a password file; it should not read or delete some files that it should not delete.

This is more dangerous if the program is running as root instead of a dedicated user because it will have access to all files of the machine if proper security techniques have not been applied.

With these solutions, if a program tries to do something it is not designed for, it will be killed by the kernel and the execution of the program will terminate.

To do that, the source code of the program should be modified with some “more or less” simple lines of code that will “describe” which system calls the program is allowed to request.

A system call is the programmatic way in which a computer program requests a service from the kernel of the operating system it is executed on, by allowing only a subset of the system calls we can mitigate security bugs.

Last year, for example, memcached, a popular application designed to speed up dynamic web applications, has suffered by a remote code execution bug that could be exploited to remotely run arbitrary code on the targeted system, thereby compromising the many websites that expose Memcache servers accessible over the Internet.

With a solution like seccomp(2) or pledge(2), a similar bug could be mitigated, the remote code would never be executed, and the memcached process would be terminated.

Linux.com: What’s the main difference between the two solutions?

Bechis: The main difference (at least the more visible one without viewing under the hood) between Linux and OpenBSD implementation is that, with Linux seccomp(2), you can instruct the program in a very granular way, and you can create very complex policies, while on OpenBSD pledge(2) permitted syscalls have been grouped so policies will be simpler.

On the other hand, using seccomp(2) in Linux could be difficult, while OpenBSD pledge(2) is far easier to use.

On both operating systems, every program should be studied in order to decide which system call the application could use, and there are some facilities that can help understand how a program is operating, what it is doing, and which operations it should be allowed to do.

Learn more at Open Source Summit, taking place in Prague, Czech Republic Oct. 23- 26. Register now!