Community

Loadsharers: Funding the Load-Bearing Internet Person

Eric S. Raymond — Wed, 07 Aug 2019 23:00:00 +0000

The internet has a sustainability problem. Many of its critical services depend on the dedication of unpaid volunteers, because they can't be monetized and thus don't have any revenue stream for the maintainers to live on. I'm talking about services like DNS, time synchronization, crypto libraries—software without which the net and the browser you're using couldn't function.

These volunteer maintainers are the Load-Bearing Internet People (LBIP). Underfunding them is a problem, because underfunded critical services tend to have gaps and holes that could have been fixed if there were more full-time attention on them. As our civilization becomes increasingly dependent on this software infrastructure, that attention shortfall could lead to disastrous outages.

I've been worrying about this problem since 2012, when I watched a hacker I know wreck his health while working on a critical infrastructure problem nobody else understood at the time. Billions of dollars in e-commerce hung on getting the particular software problem he had spotted solved, but because it masqueraded as network undercapacity, he had a lot of trouble getting even technically-savvy people to understand where the problem was. He solved it, but unable to afford medical insurance and literally living in a tent, he eventually went blind in one eye and is now prone to depressive spells.

More recently, I damaged my ankle and discovered that although there is such a thing as minor surgery on the medical level, there is no such thing as "minor surgery" on the financial level. I was looking—still am looking—at a serious prospect of either having my life savings wiped out or having to leave all 52 of the open-source projects I'm responsible for in the lurch as I scrambled for a full-time job. Projects at risk include the likes of GIFLIB, GPSD and NTPsec.

That refocused my mind on the LBIP problem. There aren't many Load-Bearing Internet People—probably on the close order of 1,000 worldwide—but they're a systemic vulnerability made inevitable by the existence of common software and internet services that can't be metered. And, burning them out is a serious problem. Even under the most cold-blooded assessment, civilization needs the mean service life of an LBIP to be long enough to train and acculturate a replacement.

(If that made you wonder—yes, in fact, I am training an apprentice. Different problem for a different article.)

Alas, traditional centralized funding models have failed the LBIPs. There are a few reasons for this:

Go to Full Article

Open Source Is Good, but How Can It Do Good?

Glyn Moody — Mon, 05 Aug 2019 11:00:00 +0000

by Glyn Moody

Open-source coders: we know you are good—now do good.

The ethical use of computers has been at the heart of free software from the beginning. Here's what Richard Stallman told me when I interviewed him in 1999 for my book Rebel Code:

The free software movement is basically a movement for freedom. It's based on values that are not purely material and practical. It's based on the idea that freedom is a benefit in itself. And that being allowed to be part of a community is a benefit in itself, having neighbors who can help you, who are free to help you—they are not told that they are pirates if they help you—is a benefit in itself, and that that's even more important than how powerful and reliable your software is.

The Open Source world may not be so explicit about the underlying ethical aspect, but most coders probably would hope that their programming makes the world a better place. Now that the core technical challenge of how to write good, world-beating open-source code largely has been met, there's another, trickier challenge: how to write open-source code that does good.

One obvious way is to create software that boosts good causes directly. A recent article on opensource.com discussed eight projects that are working in the area of the environment. Helping to tackle the climate crisis and other environmental challenges with free software is an obvious way to make the world better in a literal sense, and on a massive scale. Particularly notable is Greenpeace's Platform 4—not just open-source software, but an entire platform for doing good. And external coders are welcome:

Co-develop Planet 4!

Planet 4 is 100% open source. If you would like to get involved and show us what you've got, you're very welcome to join us.

Every coder can contribute to the success of P4 by joining forces to code features, review plugins or special functionalities. The help of Greenpeace offices with extra capacity and of the open source community is most welcome!

This is a great model for doing good with open source, by helping established groups build powerful codebases that have an impact on a global scale. In addition, it creates communities of like-minded free software programmers interested in applying their skills to that end. The Greenpeace approach to developing its new platform, usefully mapped out on the site, provides a template for other organizations that want to change the world with the help of ethical coders.

Go to Full Article

When Choosing Your Commercial Linux, Choose Wisely!

Vince Calandra — Wed, 17 Jul 2019 12:00:00 +0000

by Vince Calandra

“Linux is Linux is Linux,” is a direct quote I heard in a meeting I had recently with a major multi-national, critical-infrastructure company. Surprisingly and correctly, there was one intelligent and brave engineering executive who replied to this statement, made by one of his team members, with a resounding, “That’s not true.” Let’s be clear, selecting a commercial Linux is not like selecting corn flakes. This is especially true when you are targeting embedded systems. You must be considering key questions regarding the supplier of the distribution, the criticality of the target application, security and life-cycle support for your product.

Choose Wisely

There is a wonderful scene in the movie Indiana Jones and the Last Crusade when our hero, Indiana, must select the true Holy Grail. Set before him is a multitude of cups ranging from opulent, bejeweled challises to simple clay drinking cups. If you have seen the movie, Indiana reasons out the best choice, and it was a life or death selection. The knight who had been guarding the challises for centuries famously says, “You chose… wisely.” Why bring up this iconic scene? When you are selecting a commercial Linux distribution, you have a multitude of choices all bejeweled with wonderful marketing. The bottom line is that you want to save dollars that you would have otherwise spent on a DIY-Linux approach and ensure the commercial Linux selected fits your particular application. Here are some questions that you will need to keep in mind:

Is this for an IT application?
Is this for an OT (Operational Technology) application?
How long will this system be in the field?
What processes and procedures are used by my supplier to cover security vulnerabilities?
Can my supplier integrate in other Linux packages that support functionality I need going forward?

This is the short list. Other elements to keep in mind are the specific distribution’s origin and the Open Source community upon which it is based. How important is that specific Linux supplier with regard to the Open Source community upon which the distribution is based? These elements need to be part of the thought process.

I’ll Let My Silicon Choose

Go to Full Article

Ten Years of "Linux in the GNU/South": an Overview of SELF 2019

Matthew R. Higgins — Wed, 26 Jun 2019 12:00:00 +0000

by Matthew R. Higgins

Highlights of the 2019 Southeast LinuxFest.

The tenth annual SouthEast LinuxFest (SELF) was held on the weekend of June 14–16 at the Sheraton Charlotte Airport Hotel in Charlotte, North Carolina. Still running strong, SELF serves partially as a replacement for the Atlanta Linux Showcase, a former conference for all things Linux in the southeastern United States. Since 2009, the conference has provided a venue for those living in the southeastern United States to come and listen to talks by speakers who all share a passion for using Linux-based operating systems and free and open-source software (FOSS). Although some of my praises of the conference are not exclusive to SELF, the presence of such a conference in the "GNU/South" has the long-term potential to have a significant effect on the Linux and FOSS community.

Despite facing several challenges along the way, SELF's current success is the result of what is now ten years of hard work by the conference organizers, who currently are led by Jeremy Sands, one of the founding members of the conference. Scanning through the materials for SELF 2019, however, there is no mention that this year's conference marked a decade of "Linux in the GNU/South". It actually wasn't until the conference already was over that I realized this marked SELF's decennial anniversary. I initially asked myself why this wasn't front and center on event advertisements, but looking back on SELF, neglecting questions such as "how long have we been going?" and instead focusing on "what is going on now?" and "where do we go from here?" speaks to the admirable spirit and focus of the conference and its attendees. This focus on the content of SELF rather than SELF itself shows the true passion for the Linux community rather than any particular organization or institution that benefits off the community.

Another element worthy of praise is SELF's "all are welcome" atmosphere. Whether attendees were met with feelings of excitement to return to an event they waited 362 days for or a sense of apprehension as they stepped down the L-shaped hall of conference rooms for the first time, it took little time for the contagious, positive energy to take its effect. People of all ages and all skill levels could be seen intermingling and enthusiastically inviting anybody who was willing into their conversations and activities. The conference talks, which took all kinds of approaches to thinking about and using Linux, proved that everybody is welcome to attend and participate at the event.

Go to Full Article

We Need to Save What Made Linux and FOSS Possible

Doc Searls — Wed, 08 May 2019 13:11:53 +0000

by Doc Searls

If we take freedom and openness for granted, we'll lose both. That's already happening, and we need to fight back. The question is how.

I am haunted by this passage in a letter we got from reader Alan E. Davis (the full text is in our Letters section):

...the real reason for this letter comes from my realization—in seeking online help—that the Linux Documentation Project is dead, and that the Linuxprinting.org project—now taken over by open printing, I think, is far from functioning well. Linux has been transformed into containers, and embedded systems. These and other such projects were the heart and soul of the Free Software movement, and I do not want for them to be gone!

This is the kind of thing Bradley Kuhn (of the Software Freedom Conservancy) lamented in his talk at Freenode.live last year. So did Kyle Rankin in his talk at the same event (video, slides and later, an LJ article). In an earlier conversation on the same stage (it was a helluva show), Simon Phipps (of the Open Source Initiative) and I had our own lamentations.

We all said it has become too easy to take Linux and FOSS for granted, and the risks of doing that were dire. Some specifics:

Go to Full Article

A Conversation with Kernel Developers from Intel, Red Hat and SUSE

Bryan Lunduke — Tue, 30 Apr 2019 11:30:00 +0000

by Bryan Lunduke

Three kernel developers describe what it's really like to work on the kernel, how they interact with developers from other companies, some pet peeves and how to get started.

Like most Linux users, I rarely touch the actual code for the Linux kernel. Sure, I've looked at it. I've even compiled the kernel myself on a handful of occasions—sometimes to try out something new or simply to say I could do it ("Linux From Scratch" is a bit of a right of passage).

But, unless you're one of the Linux kernel developers, odds are you just don't get many opportunities to truly look "under the hood".

Likewise, I think for many Linux users (even the pro users, sysadmins and developers), the wild world of kernel development is a bit of a mystery. Sure, we have the publicly available Linux Kernel Mailing List (LKML.org) that anyone is free to peruse for the latest features, discussions and (sometimes) shenanigans, but that gives only a glimpse at one aspect of being a kernel developer.

And, let's be honest, most of us simply don't have time to sift through the countless pull requests (and resulting discussions of said pull requests) that flood the LKML on a daily basis.

With that in mind, I reached out to three kernel developers—each working at some of the most prominent Linux contributing companies today—to ask them some basic questions that might provide a better idea of what being a Linux kernel developer is truly like: what their days look like and how they work with kernel developers at other companies.

Those three developers (in no particular order):

Dave Hansen, Principal Engineer, System Software Products at Intel.
Josh Poimboeuf, Principal Software Engineer on Red Hat Enterprise Linux.
Jeff Mahoney, Team Lead of Kernel Engineering at SUSE Labs.

Intel, Red Hat and SUSE—three of the top contributors of code to the Linux kernel. If anyone knows what it's like being a kernel developer, it's them.

I asked all three the exact same questions. Their answers are here, completely unmodified.

Bryan Lunduke: How long have you been working with the Linux kernel? What got you into it?

Dave Hansen (Intel): My first experience for the Linux kernel was a tiny little device driver to drive the eight-character display on an IBM PS/2, probably around 20 years ago. I mentioned the project on my college resume, which eventually led to a job with IBM's Linux Technology Center in 2001. IBM is where I started doing the Linux kernel professionally.

Go to Full Article

The Kids Take Over

Doc Searls — Mon, 08 Apr 2019 11:30:00 +0000

by Doc Searls

As with Linux, these kids are all about making things—and then making them better. They're also up against incumbent top-down systems they will reform or defeat. Those are the only choices.

It starts here, in the heart of Long Island, a couple dozen exits east of Queens. I saw it with my own eyes in Mineola's Public Schools, where kids, led by a nonprofit called kidOYO ("kid-oh-yo"), are learning to program in different languages on different devices and operating systems, creating and re-creating software and hardware, with fun and at speed. Their esteem in themselves and in the eyes of their peers derives from their actual work and their helpfulness to others. They are also moving ahead through levels of productivity and confidence that are sure to create real-world results and strip the gears of any system meant to contain them. Mineola's schools are not one of those systems.

OYO means Own Your Own, and that's what these kids are learning to do. In geekier terms, they are rooting their own lives online. They're doing it by learning to program in languages that start with Scratch and progress through Python, Java, C# and beyond. They're doing it on every hardware and software platform they can, while staying anchored to Linux, because Linux is where the roots of personal freedom and agency go deepest. And they're doing in all in the spirit of Linus' book title: just for fun.

With kidOYO, the heuristics go both ways: kidOYO teaches the kids, and the kids teach kidOYO. Iteration is constant. What works gets improved, and what doesn't gets tossed. The measures of success are how enthused the kids stay, how much they give and get energy from each other, and how much they learn and teach. Nowhere are they sorted into bell curves or given caste-producing labels, such as "gifted" or "challenged". Nor are they captive to the old report-card system. When they do take standardized tests, for example the college AP (advanced placement) ones for computer science, they tend to kick ass.

kidOYO is the creation of the Loffreto family: Devon and Melora, and their son Zhen, who is now 13. What started as a way to teach computing to Zhen turned into ways to teach computer science to every kid, everywhere. kidOYO's methods resemble how the Linux kernel constantly improves, with code contributors and maintainers stamping out bugs and iterating toward ever-expanding completeness, guided by an equal mix of purpose and fun.

Go to Full Article

Some Thoughts on Open Core

Kyle Rankin — Fri, 18 Jan 2019 13:00:00 +0000

by Kyle Rankin

Why open core software is bad for the FOSS movement.

Nothing is inherently anti-business about Free and Open Source Software (FOSS). In fact, a number of different business models are built on top of FOSS. The best models are those that continue to further FOSS by internal code contributions and that advance the principles of Free Software in general. For instance, there's the support model, where a company develops free software but sells expert support for it.

Here, I'd like to talk a bit about one of the more problematic models out there, the open core model, because it's much more prevalent, and it creates some perverse incentives that run counter to Free Software principles.

If you haven't heard about it, the open core business model is one where a company develops free software (often a network service intended to be run on a server) and builds a base set of users and contributors of that free code base. Once there is a critical mass of features, the company then starts developing an "enterprise" version of the product that contains additional features aimed at corporate use. These enterprise features might include things like extra scalability, login features like LDAP/Active Directory support or Single Sign-On (SSO) or third-party integrations, or it might just be an overall improved version of the product with more code optimizations and speed.

Because such a company wants to charge customers to use the enterprise version, it creates a closed fork of the free software code base, or it might provide the additional proprietary features as modules so it has fewer problems with violating its free software license.

The first problem with the open core model is that on its face it doesn't further principles behind Free Software, because core developer time gets focused instead of writing and promoting proprietary software. Instead of promoting the importance of the freedoms that Free Software gives both users and developers, these companies often just use FOSS as a kind of freeware to get an initial base of users and as free crowdsourcing for software developers that develop the base product when the company is small and cash-strapped. As the company get more funding, it's then able to hire the most active community developers, so they then can stop working on the community edition and instead work full-time on the company's proprietary software.

Go to Full Article

Best Linux Marketing Campaigns

Bryan Lunduke — Wed, 05 Dec 2018 13:00:00 +0000

by Bryan Lunduke

I have long held the opinion that one of the biggest problems holding back Linux-based systems from dominating (market-share-wise) in the desktop computing space...is marketing. Our lack of attention-grabbing, hearts-and-minds-winning marketing is, in my oh-so-humble opinion, one of the most glaring weaknesses of the Free and Open Source Software world.

But, in a way, me saying that really isn't fair.

The reality is that we have had some truly fantastic marketing campaigns through the years. A few even managed to break outside our own Linux-loving community. Let's take a stroll through a few of my favorites.

From my vantage point, the best marketing has come from two places: IBM (which is purchasing Red Hat) and SUSE. Let's do this chronologically.

IBM's "Peace. Love. Linux."

Back in 2001, IBM made a major investment in Linux. To promote that investment, obviously, an ad campaign must be launched! Something iconic! Something catchy! Something...potentially illegal!

Boy, did they nail it.

"Peace. Love. Linux." Represented by simple symbols: a peace sign, a heart and a penguin, all in little circles next to each other. It was visually pleasing, and it promoted happiness (or, at least, peace and love). Brilliant!

IBM then paid to have more than 300 of these images spray-painted across sidewalks all over San Francisco. The paint was supposed to be biodegradable and wash away quickly. Unfortunately, that didn't happen—many of the stencils still were there months later.

And, according to the mayor, "Some were etched into the concrete, so, in those cases, they will never be removed."

The response from the city was...just as you'd expect.

After months of discussion, the City of San Francisco fined Big Blue $100,000, plus any additional cleanup costs, plus legal fees.

On the flip-side, the stories around it made for a heck of a lot of advertising!

IBM's "The Kid"

Remember the Linux Super Bowl ad from IBM? The one with the little boy sitting in a room of pure white light?

"He's learning. Absorbing. Getting smarter every day."

When that hit in 2004, it was like, whoa. Linux has made it. IBM made a Super Bowl ad about it!

"Does he have a name? His name...is Linux."

That campaign included Penny Marshall and Muhammad Ali. That's right. Laverne from Laverne & Shirley has endorsed Linux in a Super Bowl ad. Let that sink in for a moment.

Go to Full Article

Time for Net Giants to Pay Fairly for the Open Source on Which They Depend

Glyn Moody — Mon, 05 Nov 2018 13:00:00 +0000

by Glyn Moody

Net giants depend on open source: so where's the gratitude?

Licensing lies at the heart of open source. Arguably, free software began with the publication of the GNU GPL in 1989. And since then, open-source projects are defined as such by virtue of the licenses they adopt and whether the latter meet the Open Source Definition. The continuing importance of licensing is shown by the periodic flame wars that erupt in this area. Recently, there have been two such flarings of strong feelings, both of which raise important issues.

First, we had the incident with Lerna, "a tool for managing JavaScript projects with multiple packages". It came about as a result of the way the US Immigration and Customs Enforcement (ICE) has been separating families and holding children in cage-like cells. The Lerna core team was appalled by this behavior and wished to do something concrete in response. As a result, it added an extra clause to the MIT license, which forbade a list of companies, including Microsoft, Palantir, Amazon, Motorola and Dell, from being permitted to use the code:

For the companies that are known supporters of ICE: Lerna will no longer be licensed as MIT for you. You will receive no licensing rights and any use of Lerna will be considered theft. You will not be able to pay for a license, the only way that it is going to change is by you publicly tearing up your contracts with ICE.

Many sympathized with the feelings about the actions of the ICE and the intent of the license change. However, many also pointed out that such a move went against the core principles of both free software and open source. Freedom 0 of the Free Software Definition is "The freedom to run the program as you wish, for any purpose." Similarly, the Open Source Definition requires "No Discrimination Against Persons or Groups" and "No Discrimination Against Fields of Endeavor". The situation is clear cut, and it didn't take long for the Lerna team to realize their error, and they soon reverted the change:

Go to Full Article