A very public spat between the founder of the elementary OS Linux distribution and one of the board members for Software in the Public Interest (SPI) in early February got kind of ugly. As with any dispute of this nature, there were various claims and counter-claims that make it difficult to determine all of what transpired. But, based on what can be discerned, there are some wider issues to consider.

The public part of the disagreement began when elementary OS founder Daniel Foré posted on Google+ about a telephone conversation he had with Joshua Drake, who is a member of SPI's board. Foré felt that he got a "really aggressive sales call" from Drake about having elementary OS join SPI. Foré suggested that Drake wanted the project to join so that SPI could get a cut of the money that the distribution brings in. As noted in an LWN review of the first elementary OS "Freya" beta back in August, the distribution strongly encourages $10 contributions for downloading. SPI does take a 5% cut of donations for member projects for its services.

Foré obviously did not like the perceived pressure to join SPI. He pointed out that the distribution already has a legal entity behind it, but that Drake was adamant that elementary OS needed to be associated with a non-profit. Foré went on to note that because he was not interested in joining, Drake planned a "blog about how poor your product is". He concluded by saying that what Drake was doing amounted to extortion.

For his part, Drake did post on his blog about elementary OS, though that post has since been taken down. It can still be found, however, but it doesn't come off quite the way Foré predicted. Drake does criticize the project for its web presentation, in particular he was concerned that site visitors get no indication of the for-profit structure of the limited liability corporation (LLC) behind elementary OS. While Drake was certainly critical of the project/company, it's hard to say to say that he went completely overboard.

But elementary OS press lead Cassidy James Blaede was not at all happy with Drake's post. He rebutted each of the main points Drake made, though, of course, it largely boils down to a difference of opinion. Elementary OS is not shy about asking downloaders for money, but there is not much information on the web site about the corporate structure or its for-profit nature. Essentially, that is most of what Drake was complaining about in his original post. In a replacement post that was clearly intended to tamp down the flames, Drake reiterated that more concisely.

As is often the case in these kinds of conflicts, though, the toothpaste is pretty hard to get back into the tube once it gets out. Drake's original blog post, coupled with Foré's and Blaede's Google+ postings (and the inevitable comment stream accompanying them), quickly spread to reddit and Phoronix. A post from Alberto Ruiz calling SPI "despicable" probably helped fan the flames.

But, at its heart, the dispute is about transparency. Drake may have made a ham-handed approach to Foré—at best he was misunderstood, at worst he was well out-of-bounds—and his withdrawn blog post was fairly confrontational, but what he was after was not completely unreasonable. The elementary OS web site is still not clear about where donations to the project go, or that it is a for-profit organization.

There is also the question of where the money that is donated actually goes. Blaede mentioned "servers, merch to resell, and occasionally conference/travel costs and development hardware" as expenses for the project. Elsewhere, the bounties offered at Bountysource have been noted as another project expense. All of that seems perfectly reasonable, but the project/company could be more open about how it spends its money, especially when it is more aggressive than most open-source projects in soliciting donations.

Just prior to Drake and Foré's telephone conversation—presumably part of what sparked it—elementary OS had gotten a lot of flak for its posting (since revised, original here) that downloaders who choose to not pay are "pretty much cheating the system". Those words were poorly chosen, though the project clearly does feel that users should pay for its work. The revised text now reads: "We want users to understand that paying for software is important and not paying for it is an active choice." That is, at least, a less antagonistic way to put it.

There are other revisions to that post, mostly toning down some of the rhetoric, but elementary OS does have a bit of a point. While the distribution is based on Ubuntu (which is based on Debian, of course) and builds atop all of the work those projects do, elementary OS does add value that some find useful and/or compelling from a design standpoint. Traditionally, open-source projects have been fairly passive about donations, but elementary OS appears to be bucking that tradition. So far, that has led to a lot of noise in various locations, but is it really so wrong for a project to try to get enough revenue to fund its activities?

Many of the criticisms about the distribution's funding stance are that it hasn't done "enough" to deserve the level of donations it is seeking. That may well be true, but there is nothing inherently wrong with trying. There are lots of projects that are struggling due to lack of funding, along with various efforts to find funding for them (including organizations like Snowdrift.coop that we covered back in December). One could argue that elementary OS is just trying a different approach. It remains to be seen whether it will be successful or not.

On the transparency side, elementary OS could certainly do more to make it clear that it is a for-profit entity. It is not obliged to share its finances—it is far from the only company in our community with closely held financial information—but doing so might help with donations. In the final analysis, it is a company trying to find its way in the (crowded) Linux distribution space; if it isn't doing "enough" to attract funding to keep it going, perhaps it will transform into something more like what its critics would like to see. Or it may die on the vine. But its code is free, which is pretty hard to criticize.

Comments (11 posted)

Version 4.4 of the LibreOffice office suite was released in January. The 4.4 development cycle placed a significant emphasis on improving the user experience (UX) and polishing the user interface (UI), both of which are aspects of LibreOffice that have been the target of criticism in the past. Indeed, the new release does present a cleaner and more organized UI in many places—improvements that can make or break an office suite. But there are other noteworthy changes to be found in version 4.4, from improved interoperability with Microsoft Office to the results of a massive code-clean-up effort.

The latest release can be downloaded from the LibreOffice site. Linux builds are provided for 32-bit and 64-bit Intel systems, in RPM and Debian packages as well as in tar archives. There is a lengthy release notes page on the project's wiki that outlines the changes to each component (Writer, Calc, Impress, and so on).

Some of the most prominent new features, though, extend across all of LibreOffice's constituent parts—such as the UI enhancements. During Google Summer of Code (GSoC) 2014, two students worked on converting all of LibreOffice's dialog boxes to the latest GtkBuilder format, which is both smaller and easier to work with than the older Glade format. Similarly, the drop-down toolbars and sidebars have been reworked, and many (if not all) right-click context menus have been reorganized.

The tricky aspect of this sort of development work is that it can easily go unnoticed, because it is largely about removing awkwardness: fixed-sized dialog boxes, drop-down menus that require a lot of scrolling, context menus that contain unnecessary (and rarely used) items. But if one knows where to look for them, the improvements are there to see. Take the "Bullets" and "Numbers" toolbar menus in Writer, for example. Clicking on the new menu items displays a rather large preview of each available style, which makes the alternatives instantly easy to distinguish from one another—something that was not so clear in older releases. But quantifying whether this change makes writing a little easier or much easier is hard to do.

Similarly, it is easy to point out that Cut, Copy, and Paste are now in the same position in every right-click context menu, but the practical impact it has is difficult to measure. Suffice it to say, then, that LibreOffice 4.4 incorporates a wealth of such changes that, when taken together, make the office suite far less frustrating to work in.

Of particular note on the UX front, the sidebar in Writer now provides access to the Styles and Gallery functions, which were previously hidden in separate dialog boxes. Styles allows the user to apply a pre-defined formatting style to selected text (e.g., footnotes, quotations, or various headers); Gallery offers drag-and-drop access to images that the user can place into a document. Both of these are functions that a typical user may need to drop into repeatedly during an editing session, so not having to open up a new window that steals focus from the main document is a big improvement.

The content of the toolbars has been significantly rearranged as well, with an eye toward making the most-common entries the easiest to reach. For those who read left-to-right languages, that means that the common entries are the furthest to the left, and the least likely to be hidden off screen. In retrospect, this seems like a rather obvious change to make, but in earlier versions of LibreOffice, the emphasis was evidently on grouping related toolbar items together. It is hard to be objective about which approach is universally better but, at the very least, not having important tools lost off-screen is certainly an improvement.

Users of a typographic bent will notice several improvements to the way fonts and special characters are treated. The character-selection widget (which is used to insert characters not found on the current locale's keyboard) has been simplified. There are also several interesting substitutions that are now automatically inserted by the spellchecker: typing (c) will insert the © sign; (tm) will insert ™, and so on. Version 4.4 also adds a new set of open-licensed fonts (Caladea and Carlito) designed to serve as drop-in replacements for Microsoft's Cambria and Calibri—which are, essentially, the modern equivalent of the so-called "core fonts" Times New Roman and Arial.

Among the many other application-specific improvements found in the 4.4 release, Writer now supports placing text into geometric shapes (and having the text confined to the outline of the shape) and the status bar at the bottom of the window now more clearly presents information about the current page. Calc's "Statistics Wizard," which automatically analyzes a set of cells, gained several new functions (like Quartiles and the Chi-square test). Draw finally gained a zoom tool, while Impress gained improved support for using OpenGL slide transitions. All applications can now export digitally signed PDFs; users must manually load their signing certificate into LibreOffice's certificate storage in order to take advantage of the feature.

There are quite a few additional file types now readable by LibreOffice 4.4. Much of the work involved in this area comes from the Document Liberation Project, a spin-off of LibreOffice that focuses on building file-format conversion libraries. Among the newly supported formats are Adobe PageMaker, MacDraw, RealAudio, Sony's LRF e-book format, Ogg Opus multimedia, and MPEG Audio.

Perhaps of more importance at a practical level, though, is that LibreOffice 4.4 updates its support of Microsoft's OOXML format to the latest revision. A sad fact of life is that the majority of LibreOffice users still need to exchange files with Microsoft Office users on a regular basis. LibreOffice may always lag somewhat behind Microsoft when it comes to OOXML file support (indeed, it is in Microsoft's interest to make competing office suites play catch-up), but there is no denying that it is a necessary feature.

The LibreOffice project reports that it undertook a major effort during the 4.4 development cycle to perform code reviews with the Coverity scanning service. The Coverity scans reportedly turned up more than 6,000 defects—all of which were fixed. That number included more than 1700 null pointer dereferences and 1100 uninitialized members. For a project of LibreOffice's size, it is impressive to see that much ground covered in such a relatively short time.

In some ways, LibreOffice 4.4 is not an exciting release: there is no banner-worthy new feature, but a great many small improvements instead. Then again, office suites might not ever need to trade on a reputation for excitement; steady progress and stability are more important. The UI and UX improvements offer a nicer visual design and an improved workflow, respectively; that might be enough to attract some more users to the project, but if their main impact is simply to make the editing experience smoother or more pleasing for existing users, that is a worthwhile end of its own.

Comments (7 posted)

When one thinks about the PHP language, terms like "strong typing" and "strict checking" do not normally come to mind. But, as the project works toward its next major release (to be called PHP 7), it has become embroiled in a fierce debate over the proposed addition of some simple typing features to the language. To some, PHP is growing up into a safer, better-defined language, while others see the changes as possibly destroying the character of a historically freewheeling language.

Some history

PHP has traditionally taken a loose approach to types, trying to make things "just work" in almost all circumstances. A simple session in the interpreter's interactive mode shows how accommodating it can be:

$ php -a php > echo 1 + "1"; 2 php > echo 1 + true; 2 php > echo 1 + "1with_extra_junk"; 2

This flexibility undoubtedly makes PHP fun for some programmers to use; there is little of the messing around required by some other languages to keep the interpreter happy. Among other things, it allows the creation of library functions that can take a wide variety of types as parameters and do something (maybe even the right thing) with them.

But others would like to see things tightened down a bit. It would be nice, they argue, if a PHP function could count on the types of the arguments passed to it. That would enable certain kinds of errors to be caught by the interpreter; it would also make it easier to write static analyzers for the language that could be used for both correctness checking and performance improvements. These developers have made their case well enough that there is little controversy about adding some type checking; the problem arises when one tries to determine how much checking makes sense.

The specific issue at hand has to do with the passing of simple, scalar parameter types to functions — types like integers, floating-point numbers, strings, and booleans. The first attempt to add type hints for these parameter types was posted by Anthony Ferrara in 2012. It changed the function-definition syntax to look like this:

function f ((int) arg) { // "arg" is guaranteed to be int here }

This version implemented what has been termed "weak" typing, in that a non-integer argument passed to f() would be converted to the int type if possible. So floating-point numbers would be truncated, strings would be converted, etc. This proposal generated a lot of discussion that eventually bogged down; a year later, Anthony loudly bailed out of PHP development, strongly criticizing the environment found on the php-internals mailing list.

PHP voting The discussion of a vote may be surprising to those who are not familiar with how the PHP community works. Perhaps uniquely among language-development communities, PHP decides issues of language design via a vote of the developers. Issues involving an actual change to the language are deliberately hard to pass; they require a ⅔ supermajority.

Two years later (July, 2014), Andrea Faulds restarted the conversation with a new scalar type-hinting proposal. It was still a weakly typed mechanism; this time the bulk of the discussion centered on whether conversion of bogus strings ("1with_extra_junk", say) to integers should succeed or not. Yes, there are core PHP developers who believe that integer conversions should silently "succeed" in the presence of random junk. The proposal returned in September, with a request for a vote that was withdrawn shortly thereafter; yet another version came out in December.

Weak or strong?

As the various versions of the proposal went by, the real point of contention became clear. Nobody seems to object to the idea of adding scalar type hints to function definitions; the real problem had to do with how strictly they would be enforced. The "strict typing" camp wants the interpreter to disallow all implicit type conversions; if f() is defined to require an integer argument, calls like f(1.0) or f("1") should generate an error. In this view of the world, if an API developer puts type declarations onto a function, that function must be called with parameters of exactly the specified type.

The arguments for strict checking are fairly straightforward. It can catch errors that weak (or no) type checking will miss — the sort of nasty error that never happens on a developer's test system but which certain types of users can provoke easily. Strict checking lets API developers design their code with the knowledge that it will be called with the correct types. It also expands the range of static analysis options available, again turning up errors but also, it is said, opening the door to new optimization techniques.

On the other side, opponents of strong typing feel that it would drastically change the nature of the language. PHP has always allowed a high level of freedom in the mixing of types. Changing that for PHP 7 would create a language that, in their view, is not PHP. Among these folks, many of whom are core developers of the language, adding strong typing would seemingly be like trying to get Python developers to add braces or Perl developers to restrict themselves to "one way to do it." Opponents also worry that strict typing may just lead developers to write lots of casts, effectively taking away the benefits that strict typing is supposed to provide.

An attempt at compromise

Andrea appears to have despaired of ever bridging the gap between these two factions; instead, she put together a new proposal that tried to please everybody, then called for a vote. In the call, she optimistically said "I don’t think there needs to be, or will be, much further discussion"; that is not how things turned out.

The new scalar typing mechanism is still weakly typed, but with a twist. A PHP developer can add a line like this to their code:

declare(strict_types=1);

The effect of this line will be to turn on strict scalar type checking for the rest of the source file in which it is found. Library authors can add types to their function definitions; they can even turn on strict checking within the library with the above option. But it will be the author of the calling code who decides whether or not to add that line to their own code and turn on strict checking for their program.

In theory, this mechanism gives everybody what they want; developers who want to work in a strict-checking environment can have it, while those who want weak typing get it by default. In practice, this approach appears to have pleased almost nobody. Proponents of strong typing would rather see it enabled as a mandatory thing; they want callers of their functions to be required to pass the correct types. Opponents, instead, see it as a way of sneaking an alien concept into the language. PHP creator Rasmus Lerdorf also worries that it could end up breaking a lot of code and generally leading to surprising results.

To top it off, almost nobody seems to like the use of declare() which, among other things, can make it hard to tell which rules apply to a given segment of code. As Zeev Suraski put it:

If there's one thing that's worse than introducing an alien concept like strict typing into PHP, it's introducing it as a feature that will include all the negatives of this alien concept, PLUS have the ability to radically change how it behaves based on a runtime option.

Even the declare() option has proponents, though; Anthony returned to the fray to argue in its favor:

This is where the current proposal comes in. Many call it a compromise. Many call it a "worst-of-both-worlds". I call it the only way to do strict typing in PHP that won't utterly suck. The genius of this proposal is that your code controls how you call other functions. So if you want your code to be strict, any function you call will be treated strictly. But if you don't want to be strict, then the functions you call will accept weakly.

The current vote is scheduled to end on February 19. As of this writing, the results suggest that proposal might just pass with something very close to the required supermajority. In theory, that should put this long-lived debate to rest; long experience suggests, though, that an issue this contentious will not be resolved quite so easily.

Comments (148 posted)

Back in the early days, there were no user-posted comments on LWN; that feature was added, after a great deal of thought, in 2002. This was not universally regarded as a good move, but, over time, comments have become an integral part of the LWN experience. Most of the time, the comment area is interesting, respectful, and polite. But there are always exceptions.

Those exceptions lead some people to ask for more "moderation" of the comment stream.

Those of us who work on LWN have put a great deal of ourselves into it for many years. LWN is, in many ways, a labor of love. When somebody posts a comment that is offensive, abusive, spammy, or just a troll, it feels like they have painted obscene graffiti onto our houses. But we remain highly reluctant to "moderate" (or "delete," or "censor") those comments for a number of reasons. At the top of the list is the simple fact that we believe that "freedom" means more than the ability to share software with each other. To silence a voice with editorial force feels like an attack on freedom; it is not something to be done lightly.

Let there be no mistake: we do not support those who post abusive, bigoted, or demeaning comments, and we feel that there is no place for them on LWN. Our desire and goal is to run a site where that kind of comment is simply not present. But chances are that we will continue to use the heavy hand of "moderation" toward that goal rather less frequently than some would like.

Trying to control the direction of a comment stream is a slippery slope in a number of ways. In a heavily controlled environment, it is hard to tell whether the opinions on offer reflect the community, or whether they simply reflect what the moderator thinks is OK to be said. We want LWN to reflect our community, not our view of what that community should be.

What are the objective criteria by which moderation would be performed? If we try to rid the stream of anything that might be offensive to anybody, we will have a bland discussion indeed. And why stop at limiting offense? Consider that the recent call for more moderation quickly led to a request to cut off a discussion that, while admittedly long and repetitive, was focused on an area of great concern to many developers. The desire to see moderation used in such a situation shows how slippery this slope can be.

Also relevant are the facts that moderation is simply expensive and a source of legal liability. Putting together an edition every week is a serious grind; we have nobody with spare time on their hands to patrol the comments. The only way to make that kind of time available would be to reduce the number of articles we write for the site. That would be a heavy cost, and it still doesn't address the fact that unpleasant personalities feel free to post outside of LWN's business hours.

It is not surprising that a number of publications have recently taken the step of eliminating comments altogether. That is not a step we would like to take, but we will if that appears to be necessary.

But such an extreme step should not be necessary. We as a community are better than that.

Experience shows that simple requests to tone down or close off a discussion are often successful. We may well be making more such requests in the future. But the success of LWN's comment areas depends mostly on the commenters; we do not have the time, energy, or desire to play "comment nanny" all the time. If we could all make an effort to recognize when a discussion has run its course, avoid repeating ourselves, and refrain from feeding trolls, things would work better for all of us.

At the same time, we can respond to overtly offensive comments by stating, politely, that they are not welcome in our community. That, in your editor's opinion, is more likely to lead to a more respectful community in the long run than trying to moderate our way into a world where such people just do not seem to exist.

As a last resort, we may implement the ability to close down specific threads if the need arises — but we will endeavor to almost never use it. We already have the ability to block comments from specific accounts; we almost never use that either. The use of such tools is indicative of a failure at a higher level; it is a sad day when they must be put into action.

This is not the position that some people would like us to take, but it is what we feel that we are able, morally and economically, to do. And please bear in mind that comments here have gotten somewhat better over the years, even if they are still not where we would like them to be. Those with strong stomachs can look at some previous discussions for evidence of that. "Things used to be worse" is no justification for an unacceptable state of affairs now, but it does show that progress can be made. We are a community of adults, and we are certainly capable of behaving that way.

Comments (66 posted)