Leading items

Snowdrift.coop: Funding for free projects

Funding projects in the "free and open" world is a perennial problem. "Crowdfunding" using Kickstarter and other platforms has helped to alleviate some funding issues for some projects, but it is a model that targets one-time goals, not sustained development. Snowdrift.coop, which is an organization aimed at providing long-term funding for free and open projects, has—somewhat ironically—announced a crowdfunding campaign to launch itself.

There are a number of ways that today's projects raise money: fundraising campaigns offering "perks", web site buttons encouraging people to donate to the project, bounties, advertising, and so on. The Snowdrift.coop project explores existing fundraising methods on its web site and finds them lacking in various important ways. What projects need is a stable source of funding that they can depend on, while donors want a way to pick and choose which projects deserve funding. Over time, if a project is not producing what the donors want, the funding may dry up and move to another project. Snowdrift.coop is aimed at facilitating all of that.

The "snowdrift" from the name refers to the Snowdrift Dilemma, which is a variant of the Prisoner's Dilemma. If a snowdrift blocks the road in a neighborhood, everyone needs it to be cleared—eventually—but everyone gains by delaying their participation as long as possible waiting for others to start in (and perhaps finish) before them. Of course, if everyone waits, nothing actually gets done. If there were some way to do your part and be sure that the others are doing the same, the work would be fairly and equally distributed.

Snowdrift.coop is not just targeted at software projects, but at any projects that produce "soft" goods: music, art, research, and so on. These goods take a lot of effort to create, but little or no effort to copy and share. Snowdrift.coop calls these Free/Libre/Open (FLO) projects; it would like to find a way for the community (and world at large) to sustainably fund these types of projects and it believes that a many-to-many matching scheme is (at least) part of that solution.

The basic idea is that participants ("patrons" is the term Snowdrift.coop uses) agree to donate a (small) amount of money monthly to a particular project that is based on the number of other patrons that the project has. So, effectively, each new patron is matching the contribution of the existing patrons as well as new patrons that come along. The amount is one cent ($0.01) per ten patrons, so a project with 100 patrons would cost each patron ten cents per month and raise ten dollars per month. But the numbers grow quickly, so a project with 1,000 patrons costs each one dollar and raises $1,000 per month; 10,000 patrons results in $100,000.

But patrons can allocate more than just $0.01 per ten other patrons. Each unit of donation to a project (known as a "share") is, effectively, $0.001/patron (i.e. one-tenth of a cent per other patron). Multiple shares can be allocated to a project, but they are not matched by others at the same level as the initial share from a patron; in fact, each additional share is matched somewhat less. There is a somewhat complicated formula to determine the share price. The idea is to try to ensure that some wealthy donor (or, worse, project confederate) can't artificially increase the matching for everyone else by pledging an enormous number of shares. The formula determines a per-share price that applies equally to all shares.

The complexity of this calculation (and of how patrons need to think about it) has been a source of some criticisms of the project (see this thread for some examples). In practice, there may well be problems with the way multiple shares are handled, but the plan is to work them out once Snowdrift.coop is up and running.

There are some safeguards, too. Patrons are choosing to limit their donations to what they have placed into an account on the site. Anyone trying to game the system would have to spend a fair amount of money to do so. In addition, projects that benefit from any kind of manipulation are likely to find fewer patrons over time. There may need to be some kind of soft limits established as well, since users may well deposit more than they want to spend in one month, even if a million patrons sign up for the "bouncing cows" game they are a patron of.

The Snowdrift.coop project is, itself, a FLO project (of course), but unlike Kickstarter and other fundraising platforms, it will fund itself just like any other project on the site, not by taking a cut of the funding provided by patrons. But, to get going, Snowdrift.coop needs to raise some funds. The original goal of $3,000 to cover some legal expenses has already been met in the first eight days of the 30 day campaign. In fact, the first "stretch goal" of $8,000 has been met with the addition of donations that have come in from outside the Tilt.com fundraising platform.

According to the request, $3,000 was only a bare minimum needed to cover some, but not all, legal expenses required to set up Snowdrift.coop. The more than $8,000 raised so far will allow the project to continue to employ its current developer for a few more months; more donations will fund additional developers and designers. As one might guess, even higher donation levels will lead to additional benefits for the project, including conference travel, funding co-founders Aaron Wolf and David Thomas to accelerate their work on the project, and international legal assistance. For anyone curious about the project's finances, there is an accounting page that lays out the income and expenses so far.

So far, there is the web site that has a great deal of information about the project, its underpinnings and plans, as well as a working demo of the code. In the demo, you deposit fake money into your account then allocate shares to two projects. Depending on how many shares are allocated by you and others, the "monthly" donation to the projects from your account will change—reflected in the status bar of the site. For the demo, though, months will pass a bit more quickly than they do in the real world: each day is treated as a new month in the demo.

The intent is to launch the site by Spring 2015 (presumably that is the northern hemisphere Spring). The Snowdrift.coop "company" will have an interesting structure: a multi-stakeholder cooperative that is owned by those patrons who also agree to the membership agreement (which is a stub right now, but will be fleshed out before launch). The bylaws explain that each member will be in one of three classes ("General", "Project" for those who are members of projects on Snowdrift.coop, and "Snowdrift" for members of the Snowdrift.coop project) and will vote on issues appropriate to their class using range voting. Coop-wide votes will be averaged first by class, then the three class averages will be averaged—which potentially gives the smaller Snowdrift and Project classes a larger say in the outcome.

All of the projects that will be hosted by Snowdrift.coop must release their goods under an appropriate free license (e.g. for software, a license approved by OSI or FSF) as is specified in the project requirements. Projects must practice patent non-aggression and release their results in open formats as well. There is also an honor system that must be followed, with guidelines for projects and for users. The intent is to clearly set out a space where participants are respected, projects are accountable, and disagreements are defused gracefully. It all seems a little utopian, but it is clear that a lot of thought has gone into the whole idea—governance and participant behavior included.

More of that thinking can be seen in the honor guidelines for projects, for example. While not mandating the use of free-software tools, FLO-oriented hosting sites, or privacy-respecting practices, they are strongly encouraged, as are things like consensus decision-making and paying a "living wage". There are clear philosophical goals for the project, which are embodied by the "Our vision" section of the mission statement:

It's a little hard to see the straight path from a new funding model for FLO projects to achieving all of that, but there's no harm in trying. Snowdrift.coop has been more than two years in the making—and it shows. Given that there is already some success on the fundraising front, as well as some supportive blog posts (e.g. Joey Hess, Paul Chisuano, and Mike Linksvayer), Snowdrift.coop looks like it has some good ideas to go along with some momentum. That still may not be enough to reach the ideals the project has espoused, but it may well be enough to make a difference in the FLO project-funding arena—and that's certainly a good start. More is just gravy.

Comments (24 posted)

BPG, a still-image format from video compression

Fabrice Bellard, founder of both the QEMU and FFmpeg projects, recently unveiled his creation of a new lossy image file format. Called BPG (for "Better Portable Graphics"), the format is based on the compression algorithm from the High Efficiency Video Coding (HEVC) video codec. That makes it possible to achieve performance considerably better than the now 20-year-old JPEG format, but it also means that the compression comes at the cost of using patented algorithms that could be hazardous for free-software projects to implement.

HEVC is a successor to the H.264 codec, published in 2013 by MPEG and the ITU's Video Coding Experts Group (VCEG). Also known as H.265, HEVC is reported to produce the same video quality at about half the data rate of H.264. Bellard notes that a compression study published by Mozilla in July 2014 found HEVC to be the best performer by a considerable margin.

HEVC uses the same basic design as other relatively recent MPEG codecs; compression relies on an intra-picture prediction stage (which encodes "predictions" of pixel content based on the surrounding pixels in the same video frame) and an inter-picture prediction stage (which looks for similarities between successive video frames). BPG uses HEVC's intra-picture prediction only (since it only has one "frame" to worry about). But HEVC's intra-picture prediction is better than previous codec generations, and the codec uses other optimizations (such as more efficiently breaking the picture into blocks for processing) to achieve better compression ratios than H.264.

As is the case with H.264, HEVC defines several different "profiles" intended to optimize the compression algorithm for different uses. One of those is the Still Picture profile, which Bellard used as the basis for BPG's bit format. The BPG file header format is different than that of an HEVC file, however—the header is simplified, not needing to encode all of the details required of a video format. All of that adds up to a still image that Bellard says is significantly smaller than a JPEG of similar visual quality.

In addition, the format supports any bit depth from 8 to 14 bits per channel (resulting in a higher dynamic range than 8-bit-per-channel JPEG), all of the same chroma formats and color spaces as JPEG, alpha-channel transparency, and even a lossless mode (inherited from HEVC's own lossless mode). The format supports extension tags, which makes it possible to attach Exif, XMP, and other metadata.

The BPG page includes links to several pages of sample images. Viewing them requires a moderately current browser with JavaScript enabled; the page fetches each .bpg image file, decompresses it in JavaScript, and renders it as a lossless PNG images on the page inside of a <canvas> element.

As advertised, the images do exhibit fewer visual artifacts than comparably sized JPEG reference images, and BPG file sizes are noticeably smaller for the same (roughly) equivalent visual quality. Bellard provides a source code bundle for download containing a command-line encoder, decoder, and a library. The decoder and library are built on top of a stripped-down version of FFmpeg (which is included in the downloadable package) that includes only the HEVC codec, with the modifications necessary to support BPG's feature set. The encoder can use any of several HEVC implementations. The original BPG code is BSD-licensed, while the modified FFmpeg library is under LGPLv2.1.

Based on the examples shown, BPG certainly has the makings of a useful image format. The catch, however, is that it is derived from HEVC, which is patent-encumbered and royalty-bearing. That poses a major problem for free-software projects in any jurisdiction that recognizes the patents—meaning most of them.

Bellard notes, however, that because BPG's bit format is a conforming implementation of HEVC's Still Picture profile, it could be encoded or decoded by a hardware module. That might provide a way out for hardware devices that include a licensed HEVC hardware codec module—a category that would, presumably, include a lot of commercial mobile devices.

That said, ideas for new image formats come along with regularity, but even a good idea provides no guarantee that a format will take off. As recently as October, GNOME's Jasper St. Pierre announced a new animation format, for example. More to the point, as those at a number of discussion sites (such as Hacker News) have noted, the broad strokes of BPG are reminiscent of the WebP format, which is a still-image file format based on the compression from Google's WebM video format. Despite going on four years, WebP still has yet to make a serious dent in JPEG's dominance of the still-photo marketplace.

It is hard to see how the same approach, especially when saddled with the extra burden of patent encumbrance, offers much chance of success for BGP. In fact, the compression industry has been out to replace JPEG for quite a while, with very little success: JPEG 2000 and JPEG XR have yet to move the needle. And, if there was ever a poster child for an image format that keeps refusing to go away, that format would be GIF, which by all rights should have faded to obscurity more than a decade ago.

But BPG is still interesting food for thought. As free-software projects like Xiph.org work on next-generation video compression codecs like Daala, they might find it useful to watch what works and what does not work with BPG and the like. There is still plenty of room to improve still-image compression, and as BPG's samples show, new approaches like HTML <canvas> and hardware codec support make it possible to deliver new file formats with very little effort required of the user. There is no plugin required to experiment with BPG; Bellard simply cooked it up and deployed it worldwide.

Comments (47 posted)

A quick look at the new FontForge release

FontForge is the most feature-rich free-software application for building and editing font files, but that is a niche that, regrettably, attracted relatively few developers over the project's lifespan. The situation has improved considerably in the last two years, however, and the latest release introduces several significant improvements. The new features include some expansion and enhancement to the editing tools, which will appeal to existing FontForge users, but they also include other changes that may be more significant in making FontForge appealing to new users.

The FontForge project was started in 2000 by George Williams, with the initial emphasis being placed on modifying existing font files. Over the years, the scope of the application grew to encompass designing and building fonts from scratch. Williams eventually left the project, though, and for a while interest by other developers wavered considerably—updates were irregular. But the debut of the CSS @font-face rule and, with it, web fonts, kickstarted a renewed interest in fonts with FOSS licensing.

Interest in FontForge then picked back up, although it took quite a bit of time to overcome the inevitable stagnation that had developed in the codebase. These days, there are multiple active developers, several of whom even have funding from one source or another to work on the project. Starting in late 2012, development picked up in earnest, with several major feature enhancements landing—such as the support for live collaborative editing sessions that we looked at in our Libre Graphics Meeting 2013 coverage.

Over the course of the past year, a series of small, stable releases has been tagged in the FontForge GitHub repository. The latest such release, from November 26, merits special consideration. The project appears to have stopped using version numbers for releases in favor of timestamps: the latest release is tagged 20141126. Such a practice is closer to the rolling-release model than to periodic stable updates, which unfortunately can make it a little difficult to establish a useful point of comparison. In the interest of full disclosure, I should note that I find such timestamps considerably less helpful than good-old-fashioned Major.minor numbering schemes, and recently went on record about that fact on the FontForge mailing list.

Nevertheless, it is relatively easy to compare the state of today's latest release to the versions found in most major Linux distributions. A quick survey indicates that most large distributions are shipping releases from 2012 or before; Fedora 20, Ubuntu 14.10, Debian sid, and openSUSE 13.2 all provide packages from July 2012. So regardless of how the packages are designated, most users will find that FontForge has advanced considerably since the release found in their distribution repository. At the moment, source code bundles for Linux are provided, as is a personal package archive (PPA) for Ubuntu and its derivatives.

Editing

It probably goes without saying that drawing and refining glyphs is the primary function of FontForge. The new releases add several important features for this process.

The first is the ability to display several glyphs at the same time in an editing window. In prior versions, all editing was done one character at a time. That approach makes logical sense, since each letter, number, and symbol is its own slot in the font. But it ignores the way fonts are actually used—with glyphs strung together as words and sentences.

Now, when one opens a glyph-editing window (or tab), there is a text-entry field at the top, with the selected glyph already shown. The user can type other characters before or after it, and they will be displayed on the editing canvas (but not as selectable or editable curves). All the letters are spaced and kerned in the canvas as they would be in rendered text, so that the user can, in essence, edit them in context and see how they work—or don't work—together.

The rendering of points and shapes in the editing canvas itself has also been improved significantly. Older releases often exhibit jagged edges and aliased shapes for things like control points and the fill that is applied to contours when the "preview" mode is activated. Those visual artifacts can be quite distracting when trying to make precise adjustments.

In addition, there have been a lot of updates to the tools and to the way the editing canvas functions. For example, there is now a preference to make all of the control points on a glyph visible at all times—previous versions would only show the control points when part of a Bézier path was selected. By making them all visible, this feature makes it immediately obvious when curves that should be parallel are misaligned, when control points that should be equidistant are different, and so on.

Another example is seen when the user selects and drags points: the original position of the points and the contours between them are shown in green. This makes it far easier to move points along a straight line or to see how far they have moved. Similarly, there are more commonly accessed commands available in the right-click menu and better default behaviors for several of the tools. These touches are minor individually, but when taken altogether they amount to a noticeably more responsive editing experience.

Enhancements

The collaborative-editing features mentioned above (and discussed in the LGM 2013 article) are disabled in the binary packages available for download at the moment because of the less-than-common dependencies, which have been an issue for Mac OS X and Windows builds. But the features are still available for anyone compiling from source, and the ability to have more than one FontForge user access and update a font at the same time is certainly an enhancement worthy taking note of.

Some of the side effects of that work, however, are also interesting on their own merits. For instance, there is a local web server option made with Node.js that allows users to see their changes in live-preview mode within a browser window. For anyone whose fonts are of interest in web usage, this is a plus.

It is also worth pointing out that considerable effort has gone into stabilizing the Mac and Windows builds and packaging. It can be a contentious issue for free-software developers to spend a lot of time focusing on non-free operating systems but, at the user-application level, the size of the marketplaces involved are impossible to ignore. Like it or not, OS X systems dominate with the other font-production applications in use, so FontForge needs to work well and feel native there, too. LibreOffice and many other desktop-application projects have long since taken this sort of issue for granted; it is good to see that recent FontForge development has made great strides, too.

This is not to say that Linux and other Unix-like systems have gotten short shrift; far from it. FontForge used to be quite crash-prone (occasionally even corrupting data) and riddled with odd user-interface problems (pop-ups that steal focus, confusing tab orders in dialog boxes, tables that are too small for their enclosing windows, etc). These are all but gone now; FontForge is quite difficult to crash on a modern Linux desktop.

UFO

The final feature to make note of in the latest FontForge versions is the full for support for the Unified Font Object (UFO) file type. Ironically, perhaps, UFO support is something that very few existing FontForge users can make immediate use of—especially on Linux—but it does pave the way for more interesting work in the future.

UFO is an XML-based format that is primarily noteworthy because of its widespread usage as an interchange format: in the proprietary software world, there are a variety of single-purpose utilities and scripts that manipulate UFOs, in addition to support in full-fledged font editors. Among other things, UFO stores each glyph of a font in its own directory, which fans of the format say makes it easier to monitor a font for changes at a granular level—no need to re-parse the entire font, after all, if only the "g" glyph has changed.

The format specification itself is open and is maintained on GitHub. Earlier versions of FontForge supported exporting to UFO from FontForge's native text-based format (SFD, for "Spline Font Database"), but the exported files were reported to have inconsistencies between the way they interpreted the format specification and the way it was interpreted elsewhere. And, of course, a one-way conversion meant that users missed out on opportunities to incorporate other UFO tools into their workflow.

In the past year, FontForge's UFO support has been brought up to par, implementing the latest revision (UFO v3), completely mapping UFO's data structures into FontForge's internal forms, and even supporting some common UFO extensions that proprietary applications use but that have not made it into the standard. As importantly as anything else, the program now preserves all UFO data structures when round-tripping through FontForge (including UFO data irrelevant to FontForge). The program also monitors any open UFOs on disk to pick up changes immediately. That filesystem-monitoring functionality is another side benefit of the collaboration features.

So a FontForge user can now work on a UFO-formatted font, jump to another running UFO application to make some changes, and jump back to FontForge: just what everyone wants. The only hangup is that, at the moment, there are not all that many other free-software UFO applications—particularly ones that run on Linux.

But there are a few; Øyvind "Pippin" Kolås of GIMP and GEGL fame wrote a UFO-based tool called Kernagic that automates many letterspacing tasks, and Adobe's Font Development Kit for OpenType (AFDKO, which was released under the Apache 2.0 license in October) includes UFO utilities. There are also lots of individual Python scripts out there in the wild designed for UFO; Nicolas Spalinger indexes a selection at the Open Font Development Kit page; others can be found with a bit of searching.

Font design is not the largest niche in the software world—although one might argue that the need to fix and alter fonts is considerably greater than the need to design from scratch. But even that small niche is considerably larger when one considers Windows and Mac users, not just Linux users. The past few years have added significant improvements to FontForge on these non-free platforms, which makes it a competitor to the proprietary offerings, as well as (with good UFO support) a tool that can easily interoperate with them. These are excellent gains for the health of the project; the fact that those of us who use only free software operating systems get a quality font editor out of the process as well certainly sweetens the deal.

Comments (6 posted)