Leading items

Community support for free hardware

The "Spark" tablet (later renamed "Vivaldi") was first announced at the beginning of 2012; it was meant to be a fully open device that would be "designed by and usable by us on our terms". By 2014 standards the specifications and price (€200) look a bit dated, but they were not totally out of line at the time. The software stack was to be based on the Mer distribution and the Plasma Active interface. Behind it all would be an application distribution environment that would encourage free software while allowing developers to monetize their work. By all appearances, it was set to be an interesting device.

Improv followed toward the end of 2013. It was a reasonably well-equipped development board that, once again, would run Mer. The schematics were licensed under the GPL, and the anticipated profits were destined to support community resources like the Mer open build service. Interested people were encouraged to order without delay, because "we expect the first lot to sell out quickly".

Your editor, who duly put in an order for an Improv board, recently received an email saying that this board would never arrive. Instead, the developers would be making a partial refund of the cost of the board ($52 of the $75 original cost, as it turns out). In the end, there were not enough orders to cover the cost of making that first lot of boards, so the whole project has been canceled. The message also relayed the unsurprising news that the Vivaldi project, which had long been stalled and silent, would also be wound down. The project appears to have failed completely, at considerable cost to its backers.

Why might this be? According to the above-mentioned email:

Free and open hardware is indeed important, but it is worthwhile to consider "free" and "open" independently. Open hardware is fully documented and unlocked; users have the ability to put their own software onto it if they so desire. Free hardware has all of that; in addition, the designs (including, preferably, the files used as input to the manufacturing process) are made available under a free license, allowing others to modify or extend the design.

There can be little doubt of the value of open hardware. The ability to understand what the hardware does and to change how it is used (by changing its operating software) brings a great deal of freedom to users. It allows that hardware to be used in settings and for purposes that its designers could never have envisioned. One might argue that open hardware will not exist if users are unwilling to put their money where their interests are and buy that hardware. It is also worth noting that much hardware that was not intended to open tends to be forced open by determined users. The apparent ease with which much closed hardware can be jailbroken might serve to reduce the demand for truly open hardware somewhat.

That said, there are, in fact, some signs that this demand does indeed exist. The success of Arduino, or of other development boards similar to Improv, is one case in point. Google's "Nexus" program offers hardware that, while not being quite as open as we might like, is far better than what many of us would have expected just a few years ago; customers are willing to pay the substantial cost premium to buy Nexus devices rather than use the "$0" devices from carriers. The Open Compute Project has drawn substantial industry support and has published a number of open hardware designs. So the interest is certainly there.

There is, perhaps, less interest in free hardware — hardware with designs published under a free license. Free hardware might be just as important as free software, but there is a crucial difference: almost anybody with basic skills can take advantage of the freedoms offered by free software. One might "fork" a free hardware design, but, for most of us, the ability to realize any changes to that design in real hardware is beyond reach. Perhaps, someday, it will be easy to render designs into working hardware in small quantities for a reasonable cost, but that day is not here yet. Until that day comes, it should not be surprising that the issue of hardware freedom tends to get an apathetic reaction. It just doesn't seem as relevant to many in our community as software freedom does.

Meanwhile, given that there does seem to be a market for open hardware, why is it that projects like Vivaldi and Improv struggle? It is probably a simple issue of money. Creating an interesting piece of hardware, getting it built, and selling it to users is a cash-intensive business. A handful of free software developers attempting such a project funded from their savings and using a personal weblog as the primary marketing channel will probably have a hard time. Serious funding does not guarantee success — well funded products from established manufacturers fail regularly — and a lack of that funding does not guarantee failure. But, while a new software project can be started with almost no budget at all, trying to create a new piece of hardware on a shoestring budget is sailing against the wind.

So the failure of Improv and Vivaldi is not necessarily a failure on the part of the community to support an important principle. It is probably better described as yet another startup company with some interesting ideas that never quite managed to take off. Eventually somebody will likely succeed with a fully free hardware project — as Arduino has done — and they may well benefit from some of the groundwork that was done by the developers behind Improv and Vivaldi. But they will have to succeed as a business, and not just as a piece of interesting hardware design.

Comments (15 posted)

The demise of Freecode

Many long-time members of the free software community were surprised on June 18 to see the sudden announcement, seemingly without warning signs, that Freecode.com had discontinued operations. The site, which between 1997 and 2011 operated under the name Freshmeat.net, served as an index of free and open-source software projects and provided a steady news feed composed of the aggregated release announcements of thousands of indexed projects.

The shutdown notice makes it clear that the index will remain up and accessible for future reference, which has its benefits, but the news feed has been discontinued and no new updates will be made to existing entries:

It is perhaps easy to forget how different the FOSS landscape looked in 1997. Certainly it was smaller, and it was also less connected. RSS was not created until 1999, and, naturally, took some time to rise in popularity and become a common method to publish news of any sort, release announcements included. Consequently, Freshmeat's ability to stay on top of releases from a wide variety of FOSS projects filled an important niche—and was certainly more convenient than subscribing to dozens or hundreds of mailing lists.

So, too, did Freshmeat's core index, which provided a searchable, categorized database of open-source projects, including the canonical home page for each project, basic information (such as the languages used and the platforms the project was created to run on), and a history of its previous releases. If today it sounds hard to believe that Freshmeat predated the advent of RSS, it is arguably more difficult to grasp that Freshmeat predated, at least by a small margin, the rise of Google.

Google's novel approach to indexing web content eventually made it relatively reliable to find the real home page for a software project of interest, but prior to Google PageRank, the other major search engine companies still relied largely on human-moderated indexes. Thus, they served as gatekeepers, and new sites had a very different path to follow from obscurity to fame. For a niche like free software, a dedicated index was far more accurate than a general-purpose portal like Yahoo's.

But Google did come along, and with it the way that people searched for and kept track of free software projects changed. At the same time, how and where those projects maintained their presence on the web has changed many times over as well. Whereas in the 1990s, SourceForge.net was one of the only (if not the only) hosting sites dedicated to open source software projects, today there are many more options, including Google Code, GitHub, Gitorious, and a wide range of self-hosting packages for popular web frameworks—in addition, of course, to the umbrella projects like GNU that host a large portion of the community's free software still.

One might think that the dispersal of project hosting services would serve to make a dedicated index like Freshmeat more valuable, but there were other forces at work at the same time that had the opposite effect. Package management for Linux distributions changed with the creation of Apt, yum, and related tools; users could increasingly rely on their Linux distribution to not only provide installable packages of relative freshness, but for the distribution's package index to serve as its own, ad-hoc index of the available packages themselves. And there are clearly far more ways to get the word out about a new release than there were in the late 1990s, perhaps more effectively. It may even be faster to spread the news via social media than to push an announcement out to a mailing list's subscribers.

Regardless of how the technical playing field has changed, though (and as everyone knows, it continues to change, arguably faster than ever), Freshmeat also had to function as a profitable business in order keep operating. Perhaps no one will ever know whether business calculations played a significant part in the decision to stop updating the site, but Freshmeat did change hands several times over the course of its lifespan. Dice.com acquired the site (at that point, renamed to Freecode) in 2012, after a lengthy tenure at Geeknet, the company that was formerly the corporate parent of SourceForge, Slashdot, and quite a few other related FOSS properties.

It is certainly possible that Dice.com simply did not know what to do with the site, or that its staff found the arrangement unsatisfactory. In his personal retrospective after the shutdown, longtime co-maintainer Jeff Covey noted that founder Patrick Lenz had left a year ago, after having been moved over to SourceForge operations for the preceding 18 months. Covey himself had been laid off in 2010, he said, brought back as a contractor, then voluntarily quit for personal reasons about three weeks before the shutdown. One of the other two remaining maintainers also left at the same time.

Covey notes with some regret that the departures seem to have precipitated the shutdown, which came as a surprise to him:

Certainly that series of events suggests that the decision for the shutdown had at least something to do with the interest level of its owners, rather than, say, friction with the maintainers. Nevertheless, people will inevitably speculate as to whether the root cause of the shutdown was a business issue or the many changes in the way that free software is deployed and discussed online over the past 17 years.

Has the FOSS community itself already moved on? That is difficult to assess quantitatively, at least from the outside. Certainly some people still feel that Freecode or a site like it is an important resource. On June 21, Eric S. Raymond posted a blog entry proposing a replacement site be created. He cites Freecode's independence from Linux distributions and project-hosting services, as well as its searchable index of project metadata, as vital features. Some of the same functionality is provided in other places, such as Ohloh, he notes, but none replicate the essential indexing and release-news features.

Time will tell if Raymond's proposal bears fruit; it certainly spawned a lengthy and detailed discussion among commenters. But even a full, functional replacement will only be a recreation of the now-gone original—and will, no doubt, have to cope with the same set of challenges as that original. Coping with them and delivering a valuable service for as long as Freshmeat/Freecode did would be a tall order to fill.

Comments (8 posted)

Where does the RHEL 7 source code live?

When the much-anticipated Red Hat Enterprise Linux (RHEL) 7 release was made on June 10, it started the process for various RHEL-rebuild distributions to get their new releases out. Previously, the starting point had been source RPM (SRPM) files that Red Hat used to release. Things have changed a bit this time, which caused some initial consternation among some rebuild developers, but it eventually turned out that it would not to be too difficult to get what is needed from the new Git-based repository.

The expected location for the SRPMS directory for RHEL 7 just has a README file that points to git.centos.org/project/rpms and the Red Hat Customer Portal as locations for the source code. The latter is, as its name would imply, only available to Red Hat customers. That means that all of the other rebuilds need to pick up the source code from a CentOS repository, which seems a little strange—at least at first.

One of the big changes between the release of RHEL 6 and that of RHEL 7 is that CentOS, arguably the leading RHEL-rebuild distribution, joined Red Hat. That would seem to put it in the pole position for creating a RHEL 7 rebuild, but CentOS won't have any real advantages over the others. It will be using exactly the same RHEL code as all of the other distributions. Beyond that, there is a firewall between RHEL and CentOS developers. In addition, CentOS is developing and building CentOS 7 fully in the open, so anyone interested can follow along in the mailing list and Git repositories.

The README led to queries on the centos-devel mailing list (from Morten Stevens and Connie Sieh) wondering about the change in format and location for the RHEL 7 source code. The biggest concern was how to get unmodified source code that corresponds to the RHEL 7 packages and how to verify that the code had not been modified along the way. Previously, the SRPMs that were signed with Red Hat's key would suffice, but those are only available to customers through the portal now—though they may eventually "leak" since most simply contain free software.

The terse message in the README file seemingly did not go far enough to alleviate concerns about exactly what source was stored in the Git repositories. In addition to the mailing list threads, a bug was filed over the lack of SRPMs, but it was quickly closed as NOTABUG. The comment on the closing did, however, seem to clear up any confusion about the origin of the code in the CentOS Git repository—Red Hat put the source code from RHEL 7 there as a starting point for CentOS and anyone else.

Getting Red-Hat-signed SRPMs is still possible for customers, but for non-customers looking for signed SRPMs, CentOS will be providing its SRPMs once it completes the CentOS 7 development process. Those will only minimally differ from RHEL 7, mostly just removing the Red Hat branding, so they make for a better starting point for a rebuild distribution. It is certainly different than what was available before, but not necessarily worse.

It is also possible to generate SRPMs that correspond to the original RHEL 7 code from the Git repository, though those SRPMs won't be signed. There are a number of scripts hosted in the centos-git-common repository that will help perform various tasks using the Git repositories. For example, pointing into_srpm.sh at a commit or branch of interest will use the .spec file found there to create an SRPM. One can also use show_possible_srpms.sh to list the SRPMs that can be built from a particular repository; the -r option will restrict the list to those that come from the Red Hat RHEL 7 commits. There is also information on the CentOS wiki on how to work with the myriad repositories at Git.CentOS.Org.

There are concerns expressed in the bug and mailing list threads about ensuring the authenticity of the code retrieved, but Git, coupled with SSL/TLS, should be enough to alleviate that concern. Using the tools to recreate the SRPMs from the Red Hat commits to the repository, all of which is done over HTTPS (i.e. SSL/TLS), should be safe. Rebuilding the SRPMs, rather than just downloading them, may make it a little more difficult, but it does not fundamentally change what the RHEL rebuilds can get. And having the code available in Git provides an API to do things that would not have been possible with the simple "directory full of SRPMs" approach used previously. As Chris St. Pierre put it: "You no longer have to diff the ftp 'ls' output -- there are actual machine-consumable feeds and APIs to use."

There is clearly some trepidation among the non-CentOS consumers of RHEL source code, as evidenced by the thread and bug comments. But the biggest issue, in the end, seems to be more confusion than anything else. While Red Hat did mention this change in a FAQ about the CentOS merger, it probably could have done a lot more to publicize—and explain—the change. In the final analysis, it may seem a little odd to get RHEL source code from a CentOS repository, but it shouldn't pose any real barrier to anyone getting their work done.

Comments (12 posted)