The Essential Open Source Reading List: 21 Must-Read Books
Check out the list of 21 must-read books for open source program managers, recommended by members of the TODO Group.
Is your organization looking to build out an open source program or are you already managing one? If so, you're probably already considering the kinds of tools and guidance that can make your program a holistic success. That is why, in this article series, we have been covering tools for managing open source programs and providing advice from leading experts.
Now, to take your program to the next level, we offer a free guide containing an essential open source reading list. This list can help any organization launch and maintain a thriving open source program.
Specifically, the guide provides 21 must-read books for open source program managers, recommended by members of the TODO Group. These books can help your organization build a strong foundation and avoid missteps in developing your open source program.
Advice from experts is key to running a successful open source program. "It took us years of constant discussion and negotiation to break from the traditional IT setup into a more flexible environment that supports our open source development," said Ibrahim Haddad, Vice President of R&D and Head of the Open Source Group at Samsung Research. "We made it work for us and with enough persistence you also can make it work for your open source team."
The book in this list provide expert advice on how to get your open source tool collection started, how to approach issues such as licensing and governance, and much more. "A well-designed open source compliance process should simultaneously ensure compliance with the terms of open source licenses and also help companies protect their own intellectual property and that of third-party suppliers from unintended disclosure and/or other consequences," notes Haddad.
Here are just some of the titles on the essential open source reading list:
Codev2 by Lawrence Lessig: A classic treatise on Internet regulation and the role of code as a form of law
New Frontiers in Open Innovation by Henry William Chesbrough: A thorough examination of research conducted to date on open innovation
Managing 3rd-Party Software Licenses by Giles Middleton: Covers not only license types, but methods of handling and tracking components and their licenses
Open Source for Business: A Practical Guide to Open Source Software Licensing by Heather Meeker: A downloadable ebook on licensing and legal terms
Producing Open Source Software: How to Run a Successful Free Software Project by Karl Fogel: From your mission statement to project fruition, don't miss these guidelines
The Art of Community: Building the New Age of Participation by Jono Bacon: Sound advice from one of the most respected of all community managers
The free reading list can help you navigate all kinds of common open source-related challenges. It covers everything from evaluating ROI to optimizing practices, and it explores how to seamlessly and safely leverage existing tools to complement your open source creations. It is one of a new collection of free guides from The Linux Foundation and The TODO Group that are targeted at organizations running open source programs or considering them.
The guides are available now and they can help you run an open source program office where open source is supported, shared, and leveraged. They can also, in many instances, keep your program out of trouble, where trouble can range from licensing skirmishes to lawsuits.
These free resources were produced based on expertise from open source leaders, including advice from many members of The TODO Group, which includes Autodesk, Comcast, Dropbox, Facebook, Google, Intel, Microsoft, Netflix, Red Hat, Salesforce, and Samsung.
Also, don't miss the previous articles in the series:
How to Create an Open Source Program
Tools for Managing Open Source Programs
Measuring Your Open Source Program's Success
Effective Strategies for Recruiting Open Source Developers
Participating in Open Source Communities
Using Open Source Code
Launching an Open Source Project: A Free Guide
Practical Ways to Improve Your Open Source Development Impact
December 29, 2017 /by Sam Dean
https://live-linux-foundation.pantheonsite.io/wp-content/uploads/lf_logo.svg 0 0 Sam Dean https://live-linux-foundation.pantheonsite.io/wp-content/uploads/lf_logo.svg Sam Dean2017-12-29 06:00:352018-03-22 15:19:41The Essential Open Source Reading List: 21 Must-Read Books
Linux Kernel Developer: Shuah Khan
Shuah Khan, of Samsung Research America, is a Linux kernel contributor and maintainer.
The Linux kernel development community remains extremely busy, as shown in the recent Linux Kernel Development Report, written by Jonathan Corbet and Greg Kroah-Hartman. Since the 4.7 release, just under 83,000 changesets have been merged from 4,319 individual developers representing 519 known corporations. Part of this busy development process involves the kernel testing infrastructure. According to the report, the "zero-day build and boot robot" system alone found 223 bugs (all of which were fixed) during the most recent reporting period. The in-kernel self-test framework continues to improve and will someday be a comprehensive test suite for the kernel.
Shuah Khan
Shuah Khan, Senior Linux Kernel Developer at Samsung Research America, is the maintainer of the kernel self-test framework. In this article, Khan answers a few questions about her work on the Linux kernel.
The Linux Foundation: What role do you play in the community and what subsystem(s) do you work on?
Shuah Khan: I maintain the Linux kernel self-test framework and USB-over-IP driver. I also contribute to the Linux Media, Power Management, IOMMU, and DMA areas. I publish articles related to the Linux kernel on the Samsung Open Source Group (OSG) blog and have previously written for the Linux Journal, where I authored a paper on Linux Kernel Testing and Debugging.
The Linux Foundation: What have you been working on this year?
Khan: My main focus this year has been Exynos platform upstream stability, Kselftest framework and individual tests. I contributed to improving the quality of media subsystem core, and media and drm drivers on Exynos platform. I enhanced and improved the Kselftest framework by adding support for the Test Anything Protocol and object relocation. In addition, I boot tested stable kernel release candidates and maintained the Kselftest and USB-over-IP drivers.
The Linux Foundation: What do you think the kernel community needs to work on in the upcoming year?
Khan: The Linux Kernel community should continue its focus on adding support for new hardware, harden the security, and improve quality. Focusing on effective ways to proactively detect security vulnerabilities, race conditions, and hard-to-find problems will help towards achieving the above goals. As a process issue, community would have to take a close look at the maintainer to developer ratio to avoid maintainer fatigue and bottlenecks.
The Linux Foundation: Why do you contribute to the Linux kernel?
Khan: Contributing to the Linux kernel requires a unique set of skills in addition to the technical know-how. Contributors should be open to their ideas and work challenged and questioned, be ready to accept criticism, be open and flexible to evolve their ideas and work based on feedback from other contributors. It is an iterative process of review and refinement to evolve a fix or a feature that adds value to the kernel. I enjoy the technical challenges and being part of the community that works towards a common goal of making the Linux kernel better in each release.
You can learn more about the Linux kernel development process and read more developer profiles in the full report. Download the 2017 Linux Kernel Development Report now.
December 27, 2017 /by The Linux Foundation
https://live-linux-foundation.pantheonsite.io/wp-content/uploads/lf_logo.svg 0 0 The Linux Foundation https://live-linux-foundation.pantheonsite.io/wp-content/uploads/lf_logo.svg The Linux Foundation2017-12-27 06:00:142018-03-22 15:15:41Linux Kernel Developer: Shuah Khan
How to Market an Open Source Project
In Deirdré Straughan's talk at Open Source Summit, she explained common marketing approaches and why they're important for open source projects.
The widely experienced and indefatigable Deirdré Straughan presented a talk at Open Source Summit NA on how to market an open source project. Deirdré currently works with open source at Amazon Web Services (AWS), although she was not representing the company at the time of her talk. Her experience also includes stints at Ericsson, Joyent, and Oracle, where she worked with cloud and open source over several years.
Through it all, Deirdré said, the main mission in her career has been to "help technologies grow and thrive through a variety of marketing and community activities." This article provides highlights of Deirdré's talk, in which she explained common marketing approaches and why they're important for open source projects.
Why you have to market free stuff
So, what is marketing? At its most basic, she said, marketing is about getting people to exchange their money for goods and services. So you might think: "Marketing is about selling. Open source is free. I don't have to try to sell anything, so why would I need marketing?"
Deirdré Straughan
But, you are selling something. You are selling ideas, and the currency you are requesting in return is something extremely valuable, which is people's time and attention. That may feel counterintuitive, because open source generally means giving something away, but it does have substance and it does have worth. In fact, it is so worthwhile that people contribute time, money, talent, and effort to the cause. However, they can only do that if they are aware of your project and convinced of the value of supporting it.
Additionally, competition is fierce, said Deirdré. To succeed, your project must compete for attention and support with some 25 and a half million other open source projects. Thus, open source marketing is about capturing very scarce attention and resources in a very crowded environment. It's about attracting people and resources to your project, which can be difficult to do.
According to Deirdré, the main resource projects need is people — their time and effort. They may be people who use your project, or they may be contributors. Of those who are contributors, some will work independently, often in their spare time. Others may be assigned a project by their employer, or, as is increasingly common, be specifically hired to work on a particular open source project.
"And, yes, in some cases, you are also asking for money. We would all like to believe that pure technical goodness will be rewarded, and that we should never have to think about money. However, most of us need some money to survive," she said.
Open source is increasingly supported by companies, but many companies are unsure about which projects to invest in. To succeed, your project needs to rise above the crowd and to attract not just independent contributors, but also companies that could offer material support.
Common points of failure in marketing
"Even so, marketing often fails to happen in open source. A common reason is that many people in tech despise marketing. But you shouldn't automatically recoil from the mere mention of marketing, because you need to be doing it if you want to survive. It will be difficult to do marketing well, if you go into it thinking it's sleazy," Deirdré said.
Sometimes resistance to marketing comes from a literal machismo, according to Deirdré. Marketing is considered a soft skill, a job for women, as opposed to the (ahem) "manly" work of coding. It is perceived as a lower-status role (until you get to the VP or CMO level). Other reasons for lack of marketing involve lack of funding, or simply the fact that nobody working on a project happens to know how to do it.
At its best, Deirdré said, marketing helps people understand what the technology is about, and how they can use it. It is a form of communication that is informative, truthful, convincing, and even inspiring.
There are many marketing tools readily available. First in importance, Deirdré said, is your code. GitHub is your resumé. Your basic code should be architectured purposefully and offer the capability to write libraries or modules so that the barriers to entry for a newcomer are fairly low. It should be well coded and offer tools that help people learn to use and contribute to your project.
A common pitfall relates to documentation. Many companies don't bother with it, but documentation will help attract people to your project. Documentation usually explains all the commands and parameters and what the output means. This information is necessary, but insufficient. Additional types of documentation are needed, according to Deirdré, such as, white papers, blogs, video, podcasts, and conference talks.
Once you've created all this content, you need a place to put it. Obviously, a GitHub repo is necessary, but you'll also need a website and/or wiki.
Discoverability is crucial, Deirdré said. You have created all this content, but people still have to find it. Toward that end, you should be cautious about project names. For example, if your project name is also a common word, searching for it is going to be difficult. To maximize results in a search engine, you can use keyword tags and categories that will help people find your project.
Search engine optimization is an arcane art. Being on the first page of search results for a keyword is extremely valuable. For that reason, "SEO best practice changes frequently, as search engines are in an arms race with the black hats who want to game search results," she said. "You can easily find recent tips and tricks on how to improve your rankings. However, it usually takes about a year to make any real progress in search engine rankings. You'll need patience."
Everything that touches the customer is marketing, Deirdré said. For example, consider airlines. Everything about the airline experience affects what consumers think about the airline. From buying a ticket, the check-in process, boarding, the plane ride and experience, the atmosphere of the airport, timeliness in departures and arrivals, and whether luggage arrived on time and unscathed — all of these processes and experiences help shape the consumer's opinion of the brand.
"This is also true for technology, and especially for communities and projects. Everything that somebody experiences around your project — good or bad — affects their perception of that project and whether they are going to want to participate in it," she said.
So, community is important. Community culture is important, as is diversity. Nurture your community. If your open source community is not diverse, ask yourself why, and think about how you can attract a wider range of participation.
Diversity also means diversity of contribution. Does your project recognize and value contribution beyond just the code? Again, you're asking people to help you do this work, so make sure that they're recognized for it.
Kindness also matters
Look closely at the newbie experience. What is it like onboarding someone to your technology? Think, too, about growing pains. Projects, like startups, can reach a critical inflection point, when there is rapid success but things start to fall apart, because there just aren't enough people to respond quickly.
"In conclusion, I'd like you to take away that marketing is not evil. You may already be doing it. You just may not think of some of what you're doing as marketing," Deirdré said.
"And marketing, particularly that which is appropriate for open source, is mostly stuff you're probably already doing, or at least know how to do. There are even people out there who would love to help. They're just waiting to be asked."
Deirdré Straughan is the Content Lead for the AWS Open Source Community Engagement team. Her work for AWS includes the new AWS Open Source blog and @AWSOpen on Twitter. You can find her at @deirdres on Twitter.
December 18, 2017 /by Pam Baker
https://live-linux-foundation.pantheonsite.io/wp-content/uploads/lf_logo.svg 0 0 Pam Baker https://live-linux-foundation.pantheonsite.io/wp-content/uploads/lf_logo.svg Pam Baker2017-12-18 06:00:372018-03-22 15:22:41How to Market an Open Source Project
Linux Kernel Developer: Thomas Gleixner
The top 30 Linux kernel developers have contributed about 16 percent of the total changes since the start of the Git era.
Since the beginning of the Git era (that is, the 2.6.11 release in 2005), a total of 15,637 developers have contributed to the Linux kernel, according to the recent Linux Kernel Development Report, written by Jonathan Corbet and Greg Kroah-Hartman.
Thomas Gleixner
The report states that, since the 2.6.11 release, the top 10 developers together have contributed 45,338 changes — almost 7.1 percent of the total. The top 30 developers contributed just under 16 percent of the total, as seen in the table below.
One of these top 30 developers is Thomas Gleixner, CTO at Linutronix GmbH, who serves in various kernel maintainer roles. In this article, Gleixner answers a few questions about his contributions to the Linux kernel.
Linux Foundation: What role do you play in the community and what subsystem(s) do you work on?
Thomas Gleixner: I serve various maintainer roles. The x86 architecture, the generic interrupt subsystem and the time(r) subsystem. Aside of that I'm leading the realtime preeemption project and overseeing the mainlining of it.
Linux Foundation: What's one way you have contributed to the 4.8 to 4.13 releases?
Gleixner: Reviews and other maintainer duties, reworking CPU hotplug and the timer wheel, implementing the managed interrupt facility, helping the resource director technology support along and consolidation/cleanups all over the place.
Linux Foundation: What do you think the kernel community needs to work on in the upcoming year?
Gleixner: Aside of the technical challenges, which are hard to predict, we need more effort on code cleanup and consolidation along with more capacity for reviews.
Linux Foundation: Why do you contribute to the Linux kernel?
Gleixner: First of all, it's fun, and I strongly believe that FOSS is the right way to go, but I freely admit that I also do it to earn my living.
https://live-linux-foundation.pantheonsite.io/wp-content/uploads/lf_logo.svg 0 0 The Linux Foundation https://live-linux-foundation.pantheonsite.io/wp-content/uploads/lf_logo.svg The Linux Foundation2017-12-15 06:00:242018-03-22 15:25:49Linux Kernel Developer: Thomas Gleixner
What Open Means to OpenStack
The OpenStack Foundation team has been thinking about what "open" means for the project. Learn more.
In his keynote at OpenStack Summit in Australia, Jonathan Bryce (Executive Director of the OpenStack Foundation) stressed on the meaning of both "Open" and "Stack" in the name of the project and focused on the importance of collaboration within the OpenStack ecosystem.
OpenStack has enjoyed unprecedented success since its early days. It has excited the IT industry about applications at scale and created new ways to consume cloud. The adoption rate of OpenStack and the growth of its community exceeded even the biggest open source project on the planet, Linux. In its short life of 6 years, OpenStack has achieved more than Linux did in a similar time span.
So, why does OpenStack need to redefine the meaning of the project and stress collaboration? Why now?
"We have reached a point where the technology has proven itself," said Mark Collier, the CTO of the OpenStack Foundation. "You have seen all the massive use case of OpenStack all around the globe."
Collier said that the OpenStack community is all about solving problems. Although they continue to refine compute, storage, and networking, they also look beyond that.
With big adoption and big growth, come new challenges. The OpenStack community and the OpenStack Foundation responded to those challenges and the project transformed along with changing market dynamics — evolving from integrated release to big tent to composability.
OpenStack community
One of the things that the Foundation team has been doing this year is thinking about what "open" means for the project. In the past five years, OpenStack has built a great community around it. There are more than 82,000 people from around the globe who are part of this huge community. The big question for the Foundation was, what's next for the coming five years? The first thing that they looked at was what got them to this position.
When you put this all into context, Bryce's stress on openness and collaboration makes sense. In an interview with The Linux Foundation, Bryce said, "We haven't really talked a lot about our attitude around openness. I think that it's a little bit overdue because when you look into the technology industry right now you see the term 'open' thrown around constantly. The word open gets attached to different products, it gets attached to different vendor conferences because who doesn't want something that's open."
"One of the key things has been those four opens that we use as the pillars of our community: how we write our code, how we design our systems, how we manage our development process, and how we interact as a community," said Bryce.
When you look at the stack part of OpenStack, there is no single component that builds the OpenStack cloud; there are many different components that come from different independent open source projects. These components are the part of the stack. "We're building technology stack but it's not a rigid stack and it's not a single approach to doing things. It's actually a flexible programmable infrastructure technology stack," Bryce said.
What's really interesting about these different open source projects is that in most cases they work in silos. Whether it's KVM or Open vSwitch or Kubernetes, they are developed independently of each other.
"And that's not a bad thing, actually," Byce said, "because you want experts in a topic who are focused on that. This expertise gives you a really good container orchestration system, a really good distributed storage system, a software defined networking system. But users don't run those things independently. There isn't a single OpenStack cloud on the planet that only runs software that we wrote in the OpenStack community."
Staying in sync
One big problem that the OpenStack community saw was big gaps between these projects.
"There are issues to keep in sync between these different open source projects that have different release cadence," said Bryce. "So far, we've left it to users to solve those problems, but we realized we can do better than that. And that's where the focus is in terms of collaboration."
The OpenStack community has been working with other communities from day one. Collaboration has always been the core of the project. Bryce used the example of KVM project, one of the many projects that OpenStack users use.
"When we started the OpenStack project, KVM was not widely considered a production-ready hypervisor," said Bryce. "There were a lot of features that were new, unstable and totally unreliable. But OpenStack became a big driver for KVM usage. OpenStack developers contributed upstream to KVM and that combination ended up helping both Nova and KVM mature because we were jointly delivering real use cases."
It's happening all across the board now. For example, Bryce mentioned a report from Research 451 that said that companies that already have OpenStack were adopting containers three times faster than those who don't.
Yes, the collaboration has been happening, but there is huge potential in refining that collaboration. Collier said that the OpenStack community members who have been gluing these different projects together have gained expertise in doing so. The OpenStack Foundation plans to help members of the community share this expertise and experience with each other.
"The Open Source community loves to give back," said Collier. "This collaboration is about sharing the playbook — both software and operational know how — that allows you to take this innovation and put it into production."
"Those are the missing links, the last mile of open infrastructure the users have had to do on their own. We're bringing that into the community and that's where I think the collaboration becomes critical," added Collier.
"How do you deliver that collaboration?" said Bryce. "Writing software is hard, but it becomes less hard when you get people together. That's something people forget in the open source community as we work remotely, collaborating online, from different parts of the world."
Face to Face Collaboration
Physical events like OpenStack Summit, Open Source Summit, KubeCon, and many others bring these people together, face to face.
"Meeting each other in person is extremely valuable. It builds trust and when we go back to our remote location and collaborate online, that trust makes us even more productive," said Bryce.
Going forward, OpenStack Foundation plans to make its events inclusive of all those technologies that matter to OpenStack users. They have started events like OpenStack Days that include projects such as Ceph, Ansible, Kubernetes, Cloud Foundry, and more.
"When you meet people, spend time with them and work together, you naturally start to understand each other better and figure out how to work together," said Bryce. "And that to me is a really important part of how you actually make collaboration happen."
December 13, 2017 /by Swapnil Bhartiya
https://live-linux-foundation.pantheonsite.io/wp-content/uploads/lf_logo.svg 0 0 Swapnil Bhartiya https://live-linux-foundation.pantheonsite.io/wp-content/uploads/lf_logo.svg Swapnil Bhartiya2017-12-13 06:00:222018-03-24 08:31:13What Open Means to OpenStack
Bell Is the First Carrier to Deploy the Open Source Version of ONAP in Production
Blog, Networking and Edge
"Bell has been engaged in the ONAP journey from day one and committed to get it to production to demonstrate its value," said Tamer Shenouda, Director of Network Transformation for Bell.
Bell, Canada's largest communications company, is the first in the world to deploy the open source version of the Open Network Automation Platform (ONAP) in production. Bell has built the capability to automate its data center tenant network provisioning on top of the ONAP Platform, providing its operations teams with a new tool to improve efficiency and time to market. This is the first step in using ONAP as a common platform across Bell's networks on its journey towards a multi-partner DevOps model.
As part of the company's Network 3.0 transformation initiative, Bell and its partners used Agile delivery to launch a minimum viable product with the platform and will continue to adapt it to ensure that it best supports the needs of Bell customers. This significant development sends a clear message to the industry that ONAP is ready and usable, and that carriers don't need to implement all ONAP components from day one to start production. Bell has also leveraged the capabilities of ONAP Operations Manager to simplify deployments, drastically reduce footprint and enable continuous delivery.
"Bell has been engaged in the ONAP journey from day one and committed to get it to production to demonstrate its value," said Tamer Shenouda, Director of Network Transformation for Bell. "This demonstration will encourage other partners to take a similar incremental approach in delivery and operations of the platform, and we look forward to other telecoms launching ONAP to production."
ONAP is a Linux Foundation project that unites two major open networking and orchestration projects – Open Source ECOMP and the Open Orchestrator Project (OPEN-O). ONAP brings together top global carriers and vendors, using shared knowledge to build a unified architecture that allows any network operator to automate, design, orchestrate and manage services and virtual functions.
"We're very proud to be the first member of the ONAP Project to demonstrate the viability of the platform live on our network," said Petri Lyytikainen, Bell's Vice President, Network Strategy, Services and Management. "The evolution of our advanced software-defined networks will enable us to respond even faster to the unique needs of our customers."
Bell is a founding Platinum Member of ONAP. Platinum members include: Amdocs, AT&T, China Mobile, China Telecom, Cisco, Cloudify, Ericsson, Huawei, IBM, Intel, Jio, Nokia, Orange, Tech Mahindra, Türk Telekom, Vmware, Vodafone, and ZTE.
December 11, 2017 /by Arpit Joshipura
https://live-linux-foundation.pantheonsite.io/wp-content/uploads/lf_logo.svg 0 0 Arpit Joshipura https://live-linux-foundation.pantheonsite.io/wp-content/uploads/lf_logo.svg Arpit Joshipura2017-12-11 10:56:262018-01-25 12:48:22Bell Is the First Carrier to Deploy the Open Source Version of ONAP in Production
This free guide can help you increase your development team's efficacy through and with open source contributions.
Open source programs are sparking innovation at organizations of all types, and if your program is up and running, you may have arrived at the point where maximizing the impact of your development is essential to continued success. Many open source program managers are now required to demonstrate the ROI of their technology development, and example open source report cards from Facebook and Google track development milestones.
This is where the new, free Improving Your Open Source Development Impact guide can help. The aim of the guide is to help you increase your development team's efficacy through and with open source contributions. By implementing some of the best practices laid out in the guide, you can:
Reduce the amount of work needed from product teams
Minimize the cost to maintain source code and internal software branches
Improve code quality
Produce faster development cycles
Produce more stable code to serve as the base for products
Improve company reputation in key open source communities.
Open source development requires a different approach than many organizations are accustomed to. But the work becomes easier if you have a clear plan to follow. Fortunately, a whole lot of companies and individuals have already forged a path to success in contributing to significant open source projects. They have tried and true methods for establishing a leadership role in open source communities.
This open source guide offers lessons for increasing open source development impact through specific examples. Contributing to the Linux kernel is one of the hardest challenges for open source developers. With that in mind, the guide uses this case as an example, but the lessons learned will apply to nearly any open source project you'll work with.
"It took us years of constant discussion and negotiation to break from the traditional IT setup into a more flexible environment that supports our open source development," said Ibrahim Haddad, Vice President of R&D and Head of the Open Source Group at Samsung Research. "We made it work for us and with enough persistence you also can make it work for your open source team."
Common Challenges
Notably, organizations run into common problems as they try to improve the impact of their open source inventions. The figure below shows some of the challenges that dedicated open source teams face in an enterprise setting. The Improving Your Open Source Development Impact guide can help you navigate these and other common open source-related challenges. It covers everything from evaluating ROI to optimizing practices, and it explores how to seamlessly and safely leverage existing tools to complement your open source creations.
It is one of a new collection of free guides from The Linux Foundation and The TODO Group providing valuable insight and expertise for any organization running an open source program. The guides are available now to help you run an open source program office where open source is supported, shared, and leveraged.
Check out the all the guides, and don't miss the previous articles in the series:
December 8, 2017 /by Sam Dean
https://live-linux-foundation.pantheonsite.io/wp-content/uploads/lf_logo.svg 0 0 Sam Dean https://live-linux-foundation.pantheonsite.io/wp-content/uploads/lf_logo.svg Sam Dean2017-12-08 06:00:382018-01-25 12:48:42Practical Ways to Improve Your Open Source Development Impact
Linux Kernel Developer: Kees Cook
Part of the ongoing Linux development work involves hardening the kernel against attack.
Security is paramount these days for any computer system, including those running on Linux. Thus, part of the ongoing Linux development work involves hardening the kernel against attack, according to the recent Linux Kernel Development Report.
This work, according to report authors Jonathan Corbet and Greg Kroah-Hartman, involves the addition of several new technologies, many of which have their origin in the grsecurity and PaX patch sets. "New hardening features include virtually mapped kernel stacks, the use of the GCC plugin mechanism for structure-layout randomization, the hardened usercopy mechanism, and a new reference-count mechanism that detects and defuses reference-count overflows. Each of these features makes the kernel more resistant to attack," the report states.
Kees Cook
In this series, we are highlighting some of the hard-working developers who contribute to the Linux kernel. Here, Kees Cook, Software Engineer at Google, answers a few questions about his work.
Kees Cook: Recently, I organized the Kernel Self-Protection Project (KSPP), which has helped focus lots of other developers to work together to harden the kernel against attack. I'm also the maintainer of seccomp, pstore, LKDTM, and gcc-plugin subsystems, and a co-maintainer of sysctl.
Linux Foundation: What have you been working on this year?
Cook: I've been focused on KSPP work. I've assisted many other developers by helping port, develop, test, and shepherd things like hardened usercopy, gcc plugins, KASLR improvements, PAN emulation, refcount_t conversion, and stack protector improvements.
Cook: I think we've got a lot of work ahead in standardizing the definitions of syscalls (to help run-time checkers), and continuing to identify and eliminate error-prone code patterns (to avoid common flaws). Doing these kinds of tree-wide changes continues to be quite a challenge for contributors because the kernel development model tends to focus on per-subsystem development.
Cook: I've always loved working with low-level software, close to the hardware boundary. I love the challenges it presents. Additionally, since Linux is used in all corners of the world, it's hard to find a better project to contribute to that has such an impact on so many people's lives.
December 6, 2017 /by The Linux Foundation
https://live-linux-foundation.pantheonsite.io/wp-content/uploads/lf_logo.svg 0 0 The Linux Foundation https://live-linux-foundation.pantheonsite.io/wp-content/uploads/lf_logo.svg The Linux Foundation2017-12-06 06:00:182018-01-25 12:49:28Linux Kernel Developer: Kees Cook
The OpenChain Project: From A to Community
OpenChain makes open source compliance more predictable, understandable, and efficient for all participants in the software supply chain.
Communities form in open source all the time to address challenges. The majority of these communities are based around code, but others cover topics as diverse as design or governance. The OpenChain Project is a great example of the latter. What began three years ago as a conversation about reducing overlap, confusion, and wasted resources with respect to open source compliance is now poised to become an industry standard.
The idea to develop an overarching standard to describe what organizations could and should do to address open source compliance efficiently gained momentum until the formal project was born. The basic idea was simple: identify key recommended processes for effective open source management. The goal was equally clear: reduce bottlenecks and risk when using third-party code to make open source license compliance simple and consistent across the supply chain. The key was to pull things together in a manner that balanced comprehensiveness, broad applicability, and real-world usability.
Main Pillars of the Project
The OpenChain Project has three pillars supported by dedicated work teams. The OpenChain Specification defines a core set of requirements every quality compliance program must satisfy. OpenChain Conformance allows organizations to display their adherence to these requirements. The OpenChain Curriculum provides the educational foundation for open source processes and solutions, while meeting a key requirement of the OpenChain Specification. The result is that open source license compliance becomes more predictable, understandable, and efficient for all participants in the software supply chain.
Reasons to Engage
The OpenChain Project is designed to be useful and adoptable for all types of entities in the supply chain. As such, it is important to distill its value proposition for various potential partners. Our volunteer community created a list of five practical reasons to engage:
OpenChain makes free and open source software (FOSS) more accessible to your developers. OpenChain provides a framework for shared, compliant use of FOSS. Conforming companies create an environment that supports use of FOSS internally and sharing of FOSS with partners.
OpenChain reduces overall compliance effort, saving time and legal and engineering resources. OpenChain allows companies in a supply chain to work together toward FOSS compliance and provides a consistent standard to which all must perform. By contrast, in a typical supply chain, each member of the chain has to perform FOSS compliance for software of others in the chain, wasting time and resources in a duplication of effort.
OpenChain may be adapted to your existing systems. OpenChain allows you to choose your own processes to meet its requirements. OpenChain provides resources that help you design new processes from the ground up, or you may choose to use the systems you have in place.
OpenChain helps your business teams work together toward a common goal. OpenChain provides a blueprint for your legal, engineering, and business teams to work together toward FOSS compliance.
OpenChain allows you to conform to a stable, community-backed specification. When you adopt OpenChain, you conform to a stable specification that is widely backed by industry and community participants. OpenChain was developed in an open, collaborative process, with contributors from a wide range of industries across Asia, Europe and North America. OpenChain is being formally adopted by a growing number of both small and larger companies.
Today, the OpenChain Project is addressing its goals and moving towards wider market adoption with the support of 14 Platinum members: Adobe, Arm, Cisco, Comcast, GitHub, Harman, Hitachi, HPE, Qualcomm, Siemens, Sony, Toyota, Western Digital, and Wind River. The project also has a broad community of volunteers helping to make open source compliance easier for a multitude of market segments. As we move into 2018, the OpenChain Project is well positioned for adoption by Tier 1, Tier 2, and Tier 3 suppliers in multiple sectors, ranging from embedded to mobile to automotive to enterprise to infrastructure.
Entities of all sizes are welcome to participate in the OpenChain Project. Everyone is welcome and encouraged to join our mailing list at:
https://lists.linuxfoundation.org/mailman/listinfo/openchain
You can also send private email to the Project Director, Shane Coughlan, at coughlan@linux.com.
December 4, 2017 /by Shane Coughlan
https://live-linux-foundation.pantheonsite.io/wp-content/uploads/lf_logo.svg 0 0 Shane Coughlan https://live-linux-foundation.pantheonsite.io/wp-content/uploads/lf_logo.svg Shane Coughlan2017-12-04 06:09:342018-01-25 12:49:52The OpenChain Project: From A to Community
Launching a project and then rallying community support can be complicated, but the new guide to Starting an Open Source Project can help.
Increasingly, as open source programs become more pervasive at organizations of all sizes, tech and DevOps workers are choosing to or being asked to launch their own open source projects. From Google to Netflix to Facebook, companies are also releasing their open source creations to the community. It's become common for open source projects to start from scratch internally, after which they benefit from collaboration involving external developers.
Launching a project and then rallying community support can be more complicated than you think, however. A little up-front work can help things go smoothly, and that's exactly where the new guide to Starting an Open Source Project comes in.
This free guide was created to help organizations already versed in open source learn how to start their own open source projects. It starts at the beginning of the process, including deciding what to open source, and moves on to budget and legal considerations, and more. The road to creating an open source project may be foreign, but major companies, from Google to Facebook, have opened up resources and provided guidance. In fact, Google has an extensive online destination dedicated to open source best practices and how to open source projects.
"No matter how many smart people we hire inside the company, there's always smarter people on the outside," notes Jared Smith, Open Source Community Manager at Capital One. "We find it is worth it to us to open source and share our code with the outside world in exchange for getting some great advice from people on the outside who have expertise and are willing to share back with us."
In the new guide, noted open source expert Ibrahim Haddad provides five reasons why an organization might open source a new project:
Accelerate an open solution; provide a reference implementation to a standard; share development costs for strategic functions
Commoditize a market; reduce prices of non-strategic software components.
Drive demand by building an ecosystem for your products.
Partner with others; engage customers; strengthen relationships with common goals.
Offer your customers the ability to self-support: the ability to adapt your code without waiting for you.
The guide notes: "The decision to release or create a new open source project depends on your circumstances. Your company should first achieve a certain level of open source mastery by using open source software and contributing to existing projects. This is because consuming can teach you how to leverage external projects and developers to build your products. And participation can bring more fluency in the conventions and culture of open source communities. (See our guides on Using Open Source Code and Participating in Open Source Communities) But once you have achieved open source fluency, the best time to start launching your own open source projects is simply 'early' and 'often.'"
The guide also notes that planning can keep you and your organization out of legal trouble. Issues pertaining to licensing, distribution, support options, and even branding require thinking ahead if you want your project to flourish.
"I think it is a crucial thing for a company to be thinking about what they're hoping to achieve with a new open source project," said John Mertic, Director of Program Management at The Linux Foundation. "They must think about the value of it to the community and developers out there and what outcomes they're hoping to get out of it. And then they must understand all the pieces they must have in place to do this the right way, including legal, governance, infrastructure and a starting community. Those are the things I always stress the most when you're putting an open source project out there."
The Starting an Open Source Project guide can help you with everything from licensing issues to best development practices, and it explores how to seamlessly and safely weave existing open components into your open source projects. It is one of a new collection of free guides from The Linux Foundation and The TODO Group that are all extremely valuable for any organization running an open source program. The guides are available now to help you run an open source program office where open source is supported, shared, and leveraged. With such an office, organizations can establish and execute on their open source strategies efficiently, with clear terms.
These free resources were produced based on expertise from open source leaders. Check out all the guides here and stay tuned for our continuing coverage.
https://live-linux-foundation.pantheonsite.io/wp-content/uploads/lf_logo.svg 0 0 Sam Dean https://live-linux-foundation.pantheonsite.io/wp-content/uploads/lf_logo.svg Sam Dean2017-12-01 06:00:472018-01-25 12:49:58Launching an Open Source Project: A Free Guide