The Outreach Program for Women (OPW) has been a successful tool for helping women get involved in free and open-source software projects. It originally began as a GNOME project and is still administered by the GNOME Foundation, but it may have outgrown that home. The impact of the program in terms of outreach and recruitment has been quite positive, but the administration of OPW and handling its finances has been a strain for the foundation at times, which led to a spending freeze in April. The freeze has made some wonder whether administering OPW is really something the GNOME Foundation should do—or whether a different or new organization would be the right home for the program.

Ryan Lortie started the discussion with a post that quoted the mission statement from the GNOME Foundation charter and suggested that administering OPW did not really fit within it:

OPW has become a very large part of what GNOME is doing, both in terms of money flowing through our accounts and in terms of time and effort spent. I feel that it has started to interfere with other functions of the foundation and the project. I argue that it is not a core part of our mission and that, given its growth, there are other people and organisations who are better positioned to take a leadership role here than we are. I think that the time has come to split OPW out from the GNOME foundation.

Lortie's message focused on the negative impact that he sees OPW administration having on the GNOME project, including the cash flow problems that led to the cancellation of hackfests and the delay in reimbursement for some expenses. But he is also concerned about the time being spent by board members and others on defending the project from "some of the stranger criticisms being leveled toward us". OPW is controversial, he said, and running the program is "a distraction from what should be our core goals".

As might be guessed, others in the GNOME community saw things rather differently. Máirín Duffy pointed out that the foundation does get a per-intern administrative fee from other projects that are participating: "So GNOME is far from taking on this extremely helpful and beneficial work without compensation." Former GNOME Foundation board member Emmanuele Bassi concurred with Duffy, but also said he didn't agree with Lortie's point about the criticisms coming from elsewhere in the FOSS world:

I'd really prefer more people went out defending the OPW program, and all the good that it generates, than have the foundation lose its resolve, and distance itself from one of the most successful things we as a community have achieved in terms of community outreach.

But those speaking up in the thread seemed genuinely interested in seeing OPW continue; they just wondered whether it had outgrown its original home—and whether running it was in the GNOME Foundation's best interest. Bassi said that the financial difficulties were not really caused by the OPW expenditures and that other expenses might have brought on a freeze. However, that is contrary to what a FAQ about the budget problems said. In addition, the scale of the expenses is quite different, as Germán Poo-Caamaño said. The expenses for a hackfest are on the order of $10,000, while 40 OPW interns means coming up with $220,000 on a fixed schedule.

Those kinds of numbers make a good case for OPW being run by a different organization, Olav Vitters said. He also stressed that he is "all for OPW". The amount of money that is currently being handled by the foundation for OPW rivals that of the rest of the budget, leading Pascal Terjan to comment that OPW is "getting bigger than GNOME itself", which means that the time may be ripe for some kind of independent organization to handle OPW.

Another alternative might be to extend the mission of the foundation to incorporate activities like administering OPW, as suggested by Andre Klapper and others. As Mathieu Duponchelle put it: "If outreach is considered to be an end goal of the GNOME project, then it should be included in the mission statement." But Duffy is concerned that multiple questions are being conflated; the alignment with the mission of the foundation is separate from the financial issues. The financial and administrative issues for OPW won't be solved by moving it out from under the GNOME Foundation, so she is worried that the program will suffer if that occurs.

Ekaterina Gerasimova, who is the GNOME Foundation Treasurer and one of those helping to administer OPW, outlined some of the costs associated with the program. The board had to take on a certain amount of the OPW administrative work to free up time for the foundation's administrative assistant to work on GUADEC planning, she said. If that had not happened, GUADEC might have been affected. That led Oliver Propst to propose that OPW move to Software Freedom Conservancy (SFC). That organization would look favorably on an application by OPW if the foundation wanted to do that, according to SFC President Bradley Kuhn.

In another message, Gerasimova noted that she is in favor of a move for OPW since doing so would "free up a lot of time for the board to concentrate on other areas such as spending the funds raised through the privacy campaign and seeking out sponsors for upcoming hackfests". Most of those who oppose a move seem to either be worried that it will pause or halt the progress of OPW or that moving it will cause GNOME to lose the benefits it enjoys from being associated with the program. As Allan Day put it:

OPW will need to stand on its own two feet irrespective of which organisation hosts it. Assuming that OPW can do this - and I think we probably all want it to - then what do we gain by moving it out to another organisation? All that would happen is that that organisation would get the benefits that we have been enjoying.

Day described one of those benefits in a separate message: "Again speaking as a member of the Engagement Team, I would say that OPW has made it easier for us to talk about what GNOME does in a coherent manner, rather than making it more difficult." He and others said that promoting diversity within the project should be one of the core goals for the project. It is not surprising that the "charter doesn't reflect GNOME's current mission", Day said, because it hasn't been updated in 14 years.

The mailing list thread just sort of trailed off after a bit. The board will presumably be taking up the issue soon—if it hasn't already (as was suggested in the thread). We will have to wait for an announcement or meeting minutes to see where things are headed.

But it seems clear that some kind of increase in the paid administrative side of OPW needs to happen. It is less clear whether that needs to be done within the GNOME Foundation, or whether some alternative organization (either one set up directly for OPW or an umbrella organization like SFC) would make a better home. It does seem that OPW, at least in financial terms, has grown to match or exceed that of its parent; given that many would like to see it grow further, it may someday dwarf the GNOME Foundation itself.

Any change in the status, organization, and administration of OPW should be approached carefully. Finding a way to alleviate the burdens of administering the program without upsetting the apple cart and setting the program back should be paramount. In many ways, OPW is a victim of its own success here; that success has led many other organizations to take part, but that growth has brought some hardships along with it. One way or another, though, the achievements of the program so far suggest that it will find a way to continue to make an impact on diversifying free-software projects. Whether that is done within the GNOME Foundation (presumably with additional administrative help) or somewhere else remains to be seen.

Comments (5 posted)

Zoomable user interfaces (ZUIs) — using "zooming in" and "zooming out" as the controls for an application's interface — are often a good way to manage human interactions with complex graphical information on a computer; for example, a ZUI makes intuitive sense for software maps, like OpenStreetMap. An open-source project, Eagle Mode, uses a ZUI to navigate through the filesystem, which is quite a departure from the style of well-known file managers like Nautilus and Dolphin. That makes for quite a different user experience, which is worth exploring.

Eagle Mode is developed by Oliver Hamann and licensed under GPLv3; the project began a few years ago and has been adding features since. I tried out its latest version, 0.85.0, which was released in June, on Fedora 20. There are also packages available for download for Windows, multiple Linux distributions, and a source code archive file.

Eagle Mode's ZUI may not be intuitive at first. Thankfully, there's a straightforward user guide to get started quickly. I've found it best to use it with a mouse; the official system requirements states that one should have a mouse "with three buttons (not emulated) and with a smooth-running wheel." One can zoom in the "content view" — which displays the directories and files you are looking at — by setting your pointer at a certain spot and rolling your mouse wheel up, and zoom out by rolling it down. Holding down the middle button lets one scroll by moving the mouse, instead.

A few minutes playing with Eagle Mode can lead to some pleasant surprises and an immediate sense of the value that it can provide users. For example, one can zoom into a music folder, find a subdirectory with a song one likes, and zoom into the song. The song will then load, and one click will begin playback within Eagle Mode itself. Zooming out stops playback.

Just one experience like that can trigger ideas of other practical uses. Zooming into a pictures folder lets you see previews at a glance. Zooming into a folder with a number of PDFs lets you read them. You can also snap a panel (e.g. a folder, a file, or the preview of a file's contents) into a full view quickly: "For showing a panel full-sized so that it fits into the view, double-click with the middle mouse button on the panel. And for showing a panel full-sized so that the view is completely utilized, triple-click or shift-double-click with the middle mouse button on the panel."

As with other graphical file managers, double-clicking on the file itself launches an appropriate program to handle the file in a separate window, so one could, say, double click a song to launch it in a separate music player, and then go back to Eagle Mode to navigate the filesystem again while the music plays. Another way to multitask is to simply run multiple instances of Eagle Mode itself, so that one could have an Eagle Mode window dedicated to, say, music playback, and another for browsing PDFs, and so on.

The "control view" — "a replacement for classic menu bars, tool bars and status bars" — is packed with features. There are lots of buttons and options; some are miniscule without zooming-in, though, which is an initial discoverability challenge. Like other file managers, there are integrated tools to sort files in directories (e.g. by name or date of modification), to rename or move files, to make new directories, and so on. There are also some buttons for bash commands, like chmod and grep , which can come in handy. There's even built-in chess, netwalk, and 3D minesweeper games, which, like the view of the filesystem, form discrete parts of an overarching graphical "virtual cosmos": a simulated view of the stars with different tools and functionality visible as discrete celestial bodies (seen at right).

I only had a few usability quibbles with Eagle Mode. It isn't intuitive out-of-the-box, but that's more the fault of the relative homogeneity in desktop GUI file managers than anything Eagle Mode does. The control view is powerful, but one needs to zoom-in to see many of the options, which obscures the content view, and then zoom-out to see the content again. This can feel a bit cumbersome and slow. Eagle Mode also assumes that certain packages are installed on one's system that may not be there, such as GIMP and Abiword; without these programs, there will be errors displayed when the program is instructed to show previews or open certain file types. These issues can be corrected relatively quickly by making changes to configuration files.

Speaking of the code, Eagle Mode is written in C++ and Perl and extensively documented, with both standalone information for developers and thorough comments in source code files. There is a C++ API for extending Eagle Mode's functionality; one has the option to make a plugin that "could show in the virtual cosmos and/or in the file manager, [or] a standalone application [which would show] as [its] own window on the desktop." As a test, I was able to download the source code, modify Eagle Mode to use a different program for handling office documents, and compile it in about a minute on my laptop.

With the number of different command line and GUI-based approaches to interact with the filesystem, one may question Eagle Mode's claimed efficiency improvements over its competitors. As mentioned above, there is a non-trivial learning curve to get the most out of the project, which may be enough of a time investment for non-technical users to outweigh its ostensible productivity benefits.

Eagle Mode is also a bit resource-hungry; the system requirements page describes memory requirements as: "1 GB RAM and 1 GB swap space (or more RAM). [...] If you run Eagle Mode with less memory, then your first job after starting should be to navigate to the Preferences (somewhere in the upper left area of the control and) view lessen the value for Max Megabytes Per View." Eagle Mode also recommends "an accelerated graphics driver. On UNIX-like systems it should be an accelerated X-Server with a fast XShm extension. 3D acceleration is not needed. It is not recommended to use something like a 3D desktop or composite manager, because that could slow down Eagle Mode a lot." I was surprised by the latter recommendation, as I didn't experience sluggishness on GNOME 3.10, although I do have 4 GB of RAM and Intel HD 4000 integrated graphics on my machine.

Given the learning curve and resource demands, some may feel Eagle Mode misses out in comparison to its more widely-known competitors. Some desktop environments, like GNOME, can find individual files with a tap of the Super key and typing a few letters of the file's name. Synapse, an application and file launcher, provides similar functionality to GNOME's individual file finding tool, while being lightweight and usable across a variety of desktop environments and window managers.

If speed of diving into frequently-used or half-remembered files is primary for the user, then those competitors may trump Eagle Mode. For example, hitting Super, typing "ArticleAugust21" and then Enter, remained faster for me than trying to line up Documents from my Home folder and zooming, then lining up my LWN article writing folder and zooming, then double-clicking the draft of this article. Nonetheless, Eagle Mode can beat the competition at a number of tasks, including managing folders with many pictures and skimming through a folder of PDFs to find the right one.

Down the road, some future development plans may be interesting to see, potentially including an API for writing plugins in other programming languages. There is an old video of a not-yet-publicly-released Android version [YouTube]. As a recent email correspondence with Hamann revealed, the Android version hasn't been worked on "for more than two years now, and maybe it will take some more years until I seriously come back to it. My estimation is that it requires about 400 hours of work until release. But one day it will come, for sure." He also plans to connect the API to X11 to handle "touch events and gesture programming."

Most interesting to see in the near future will be graphical effects and UI overhauls that Hamann referred in his email to me as "view animators", which include "kinetic effects for the zoom and scroll functions (e.g. swipe with mouse), animation of navigation functions like [...] bookmarks, and last but not least [...] automatically position[ing] the nearest content (a picture, a text page...) full-sized in the view." Hamann expects these changes to come out "with version 0.86.0 perhaps in November or December this year".

Perhaps most fascinating about Eagle Mode is the developer's philosophy behind the project: he believes "that ZUIs could make computing easier and faster, and that it would be a good idea to replace most GUIs by ZUIs." On the project's home page, he notes that "The Eagle Mode C++ API could be used to develop human machine interfaces, or control stations, or similar industrial applications, as [ZUIs]. If it is well done, a ZUI in that area could be very intuitive and logical to use, and it could surely improve and accelerate the work significantly". Whatever one's opinions of Eagle Mode itself, Hamann's assertion that most GUIs should be discarded in favor of ZUIs is certainly thought-provoking.

Imagine a doctor zooming through electronic patient files to quickly load up and compare X-ray results, or biologists zooming three-dimensional images from macroscopic to microscopic. Imagine a screen integrated into a gesture-detecting wall in your living room, displaying graphical abstractions for a camera, a TV, a game console, and a phone; one could zoom in with gestures to start a video chat, watch a movie, play a game, or look in your contacts list and call someone, respectively.

Eagle Mode is more than a file manager. It's a manifestation of one person's wish to challenge the way we think about how humans should interact with the computers in their everyday lives. Maybe we need to stop thinking about grey, utilitarian filing cabinets, and start thinking about soaring like an eagle, ready to zoom in on the varied landscape below.

Comments (8 posted)

At Flock 2014 in Prague, Red Hat's Richard Hughes presented an update of his work with AppData and AppStream, the under-the-hood elements that power the graphical GNOME Software Center package-installation tool used by Fedora. Although it might seem like orchestrating package information in an easy-to-browse installation tool would be a straightforward task, the process actually involves considerable work to handle all of the corner cases, ill-defined boundaries, and mutability that arise in modern software packaging.

The primary question, Hughes said, is "what is an application?" Fedora's previous graphical software installer, PackageKit, assumed a rather formal and absolute definition: application = package. But this is not really true, he said: there is often an N:N relationship between packages and applications as users think of them. Some packages install multiple applications, other applications require multiple packages, while other packages only include libraries, and some things that users regard as applications do not even appear anywhere in the menus (for example, alternate interface modes that can be launched with a special option or flag). Ultimately, the PackageKit model did not really do what users wanted, so it was time to step back and re-examine the subject.

AppData

For the purposes of a graphical installer, he said, it was decided that anything that includes a .desktop file that does not set the nodisplay property to true is an "application." This position, he noted, makes command-line only tools the domain of existing command-line package managers, rather than the graphical installer. But while the .desktop file provides much of the information that an installation tool needs (such as the application name and useful metadata like categories), it does not provide enough to describe the application in an "app store"–style installer. Additional things like screenshots and longer descriptions of the application are required.

Ubuntu had already addressed this problem in its own Software Center, adding this rich metadata to .desktop files. The GNOME Software Center team looked at this, Hughes said, but ultimately decided that stuffing too much into these files would be problematic—particularly if every .desktop file needed to include the same rich text duplicated in every translation. Instead, he started the AppData specification, which pulls out this sort of metadata into a separate XML file. AppStream is the framework that, using AppData, powers GNOME Software Center.

And keeping long descriptions and screenshot information in a separate file has other advantages beyond keeping .desktop files compact, he said. For one thing, a separate AppData file provides a place for the distributor to override package names in those instances where multiple applications all want to register for the same generic name (e.g., GNOME Calculator, KDE Calculator, and Xfce Calculator all want to claim "Calculator"). For another, keeping long-text descriptions in structured XML allows them to be more easily translated, and it allows translatable captions to be added for screenshots.

In theory, the AppData file for any given application would best be written upstream, where the developers can keep it up to date and provide the best screenshots and descriptions. Consequently, when the AppData specification had stabilized, Hughes set out to personally email more than 400 upstream application projects and asked them to help update their AppData files.

In keeping with this preference for upstream data management, AppData files include fields for a project homepage URL and an "update contact" email address. Hughes said he expects to use the contact information twice a year at most. Other URL fields are also available, such as one for a "help site" and one for a donations page, although so far these URLs are not exposed in Software Center's interface.

The weirdos

The trouble with AppData, however, is that it does not capture all of the user-installable things that people want. There are quite a few corner cases left out, each with its own set of challenges: GStreamer codecs, fonts, and input methods, for example, not to mention all of the plugins expected by users of GEdit, Firefox, Eclipse, and so forth.

So the definition of "application" has to be adjusted accordingly, to mean "anything that includes a .desktop file that does not set the nodisplay property to true ... plus these exceptions." In an attempt to tackle this problem without confusing the meaning of the existing AppData XML file, Hughes created a separate file type called MetaInfo that would associate these corner cases with an application. Software Center can see from a MetaInfo file that (for example) a particular package contains a GEdit plugin and not a standalone program; the software center can then provide a link to the plugin on its GEdit screen, where it will be most useful.

Finding all of the important corner cases and creating the appropriate MetaInfo files for them, however, has been a difficult task. Several steps are involved, Hughes said. First, RPM packages are unpacked and parsed to see which ones contain useful metadata. This is akin to a "poor man's Mock," he said. The process takes about 20 minutes to decompress and analyze all of Fedora, he said, saturating four CPU cores and 100% of the SATA bandwidth.

From the RPM analysis, alternate executables can be found (for example, Hughes explained, some photo editors can also be launched in a separate "just import pictures from the camera" mode; similarly some application packages may ship with auxiliary tools). The analysis can also find GNOME Shell extensions, menu bar applets, data packages intended for use with a specific application (like GIMP brush packs) and plugins.

Several of the corner cases still require separate treatment, though. Fonts are processed to generate a thumbnail image and screenshot of the basic character set. Codecs must be "fudged" on a case-by-case basis, though. For patent-encumbered codecs like MP3, Hughes explained, Fedora will include the codec in its AppStream search results, but the page for the codec will point users to a wiki page explaining that the codec cannot be installed automatically (and, hopefully, allowing the user to figure out what to do next).

Devil in the details

One interesting side effect of the RPM decompression and analysis process, though, is that there are a lot of opportunities to amass other interesting metadata about packages at the same time. For example, Hughes said, the analysis tool currently notes which applications have translations available, which integrate with the desktop notification area, which provide hooks for GNOME Shell's search feature, which have GObject Introspection files, which have (or lack) documentation, and which use outdated versions of important dependencies like GTK+.

For now, not all of this information is used in Fedora's version of Software Center. However, applications are given "extra stars" internally if they include useful features, and some applications are blacklisted if they are so out of date that they are of questionable value (such as GTK+1 applications). Hughes admitted that this blacklisting approach was controversial in some circles, but said that ultimately he had to make a call about where to put the cut-off. There are a few other criteria that can exclude a package from Fedora's Software Center, such as not having an icon of at least 48-by-48 pixels. If the upstream project and the community are not willing to take the steps necessary to produce that one icon, even after being asked, he said, one wonders how much interest there is in the program.

All together, Hughes said, the AppData and MetaInfo files produced by processing the entire Fedora package collection weigh in at 9MB, uncompressed. After collecting the data, naturally, he ran it through a validation process. At the moment, about 35.4% of Fedora's packages have the desired rich-text descriptions—but, he cautioned, considerably more have added them upstream, so the number will be much higher for the next Fedora release cycle.

The result, eventually, will be a much richer Software Center experience for Fedora users. A well-maintained AppData database will allow the software center to show useful recommendations, link to plugins and other add-ons, and enable users to see which applications are the most up to date. Hughes listed a few things that he still has yet to tackle, including a working ratings system (specifically, one that cannot be easily gamed by malicious users), integration with Fedora Account System (FAS) accounts (so that users can more easily install the same apps on multiple machines), and a mechanism for useful cross-application recommendations (such as noting that most Inkscape users also use MyPaint).

So, while there may be much more work to be done, the basic framework is well in place to align what the software installation tool sees as an "application" with what the user really wants.

[The author would like to thank the Fedora project for travel assistance to attend Flock 2014.]

Comments (1 posted)