Cam Citrowske on opensource.com writes:
It was March 17, 2020, and I was in my classroom at Aspen Academy. The clock was ticking. This was to be the last day of school before we, along with every other public school in Minnesota, would close due to the outbreak of the new coronavirus. I had students in my room during lunch, advisory periods, and my elective classes all doing the same thing—installing Linux onto old computers so we could give them to students who would use them for school at home during the shelter in place order. I was only going to have the kids’ help until dismissal time, but in the end, we had 17 computers ready to go. It was a start.
Ibrahim Haddad and Cedric Bail at the Linux Foundation have published a new whitepaper on solving technical debt with open source:
Technical debt, a term used in software development, refers to the cost of maintaining source code that was caused by a deviation from the main branch where joint development happens.
A broader interpretation of what constitutes technical debt is proprietary code by itself:
- A single organization has developed it.
- It is source code that the organization alone needs to carry and maintain.
- In some cases, the organization depends on a partner’s ability to maintain the code and carry that said debt.
The following symptoms can identify technical debt:
- Slower release cadence Time increases between the delivery of new features
- Increased onboarding time for new developers Onboarding new developers become highly involved due to code complexity where only insider developers are familiar with the codebase. The second manifestation of this symptom is the difficulty in retaining developers or hiring new developers.
- Increased security issues At least, experiencing more security issues than the main upstream branch.
- Increased efforts to maintain the code base Maintenance tasks become more time consuming as the body of code to maintain becomes larger and more complex.
- Misalignment with the upstream development cycle illustrated in the inability to keep pace, be aligned with the upstream development and release cycles.
How open source development provides a roadmap for digital trust, security, safety, and virtual work
Mike Dolan writes on the Linux Foundation blog:
We’re seeing a shift to virtual events, remote work cultures, virtual “happy hours,” and other means of productively working together, virtually. Many of these practices will stick with us post-pandemic. Our organization is already exploring how to use virtual events to augment future physical events (yes, they will exist again).
Virtual conferences may be a great path to offering more inclusive events where those of us unable to travel to an event physically can still find a way to participate at some level. We’re seeing the impact of virtual training and certifying professionals in freely available open source technologies — and it has a real impact on job prospects and employment. Virtual testing proctors have become an effective way to certify professionals. Similarly, virtual platforms can help facilitate mentorship and enable less experienced developers to find and connect with more skilled developers willing to lend a hand.
The coronavirus has opened the world’s eyes to the needs of systems and plans for pandemic situations. This year we will likely see technology communities and organizations adapt and develop the “playbook” for how the world does business in the face of a pandemic. But many of those practices will likely stay with us long after we defeat COVID-19.
New Kubernetes Security Specialist Certification to Help Professionals Demonstrate Expertise in Securing Container-Based Applications
Jack M. Germain writes on Tech News World:
The success of The Linux Foundation’s first virtual summit may well have set the standard for new levels of open source participation.
Summit masters closed the virtual doors of the four-day joint gathering on July 2. The event hosted the Open Source Summit + Embedded Linux Conference North America 2020 and ended with more than 4,000 registrants from 109 countries.
The online platform InXpo enabled participants to be part of a real immersive technical gathering. They also can view on-demand content of sponsor resources and conference sessions for one year.
The InXpo platform enabled attendees to:
- View 250+ informative educational sessions and tutorials, across 14 different technology tracks, and participate in live Q&A;
- Join the ‘hallway track’ and collaborate via topic-based networking lounges in group chats, and connect with attendees in 1:1 chats;
- Visit the 3D virtual sponsor showcase and booths to speak directly with company representatives, view demos, download resources, view job openings and share contact info.
The summit’s virtual format also provided attendees the chance to “gamify” their event experience by earning points and winning prizes for attending sessions, visiting sponsor booths, and answering trivia questions.
Anna-Lena wanted to improve her Linux kernel development skills, so she applied for and was awarded a Linux Foundation Training (LiFT) Scholarship in the Kernel Guru category.
The Linux Foundation has published a new blog about the use of Trademarks in open source communities:
A trademark is a word, phrase or design that denotes a “brand” that distinguishes one source of product or solution from another. The USPTO describes the usage of trademarks “to identify and distinguish the goods/services of one seller or provider from those of others, and to indicate the source of the goods/services.” Under US trademark law you are not able to effectively separate ownership of a project mark from control of the underlying open source project. While some may create elaborate structures around this, at the end of the day an important principle to follow is that the project community should be in control of what happens to their brand, the trademark they collectively built up as their brand in parallel with building up the functionality of their code.
For this reason, in communities that deem their brand important, we also file registrations for trademark protection to reserve the rights in the mark for the project, commonly in the United States, China, European Union, Japan, and other countries around the world. Registered marks will often have a ® symbol. This is different from a common law trademark right where you often see a ™ symbol with the mark. Having a registered trademark is often important because it enables us to better protect the community against misrepresentation, misuse, and confusion in the ecosystem between what is actually the community-built project, and what is not. This is often based on specific benefits that arise from the registration, which may vary from country to country.
Scott Nicholas writes at the Linux Foundation blog:
A key goal of some open collaboration efforts — whether source code or specification oriented — is to prevent technical ‘drift’ away from a core set of functions or interfaces. Projects seek a means to communicate — and know — that if a downstream product or open source project is held out as compatible with the project’s deliverable, that product or component is, in fact, compatible. Such compatibility strengthens the ecosystem by providing end-users with confidence that data and solutions from one environment can work in another conformant environment with minimal friction. It also provides product and solution providers a stable set of known interfaces they can depend on for their commercially supported offerings.
A trademark conformance program, which is one supporting program that the LF offers its projects, can be used to encourage conformance with the project’s code base or interfaces. Anyone can use the open source project code however they want — subject to the applicable open source license — but if a downstream solution wants to describe itself as conformant using the project’s conformance trademark, it must meet the project’s definition of “conformant.” Some communities choose to use words other than “conformant” including “certified”, “ready”, or “powered by” in association with commercial uses of the open source codebase. This is the approach that some Linux Foundation projects take to maintain compatibility and reduce fragmentation of code and interfaces.