Maybe software services could harm free software after all (and other news from the Open Source convention)

By Andy Oram
July 21, 2009 | Comments: 4

I just returned from the first official event--lightning talks and open source awards--at the 2009 O'Reilly Open Source Convention. It was a brisk parade of brilliant people, culminating in a whirlwind presentation by Perl wizard Damian Conway, whose only objective so far as I could see was to get the world to abandon XML and switch to pod.

Along with all the inspiring suggestions for changing software, politics, education, disabilities, and our general appreciation for life, I was particularly proud to see the high percentage of women honored for doing fantastic things and presenting them forcefully. I wished there was an even larger audience to witness the event. Ethnic diversity was not so well represented, but that can be a goal to strive for.

This blog kicks off the conference with the following sections:

Maybe software services could harm free software after all

Six months ago I wrote that Software as a Service doesn't threaten free software, trying to calm the alarms spreading through free and open source communities. The Open Source convention is a living demonstration of the convivial relationship between SaaS and free software. A large number of attendees are creating services, but they overwhelmingly use free software to build them and often contribute improvements back to free software.

What worries free software advocates is that their software can be enhanced without sharing the source, if the software is hidden behind a web interface. I claimed that this is not really a threat to the free software movement because modern languages and development tools make it so easy to replicate a service. In fact, we have so many people creating so many services that nobody has time to try all the ones that interest him.

But this week I thought of a totally different impact SaaS could have, with detrimental effects on the free software movement.

The use of SaaS spreads along with mobile devices. We don't want to drag the weight and bulk of a general-purpose computer around with us, like the laptop I'm using at the conference to write this blog. We want our digital functions on convenient mobile devices, and SaaS offers more potential for that convenience by giving us functions such as email and calendars that we used to do on general-purpose systems.

In fact, mobile devices are turning into general-purpose systems--but only because SaaS provides the features we're used to.

But desktop and laptop systems enable one use not available on cell phones and netbooks. Larger-scale systems provide the memory, compute power, screen real estate, and input devices that let us write, compile, and run software. Free software developers want larger and more powerful systems than the ones that the world is moving to.

If fewer people use desktop and laptop systems, they become premium items with correspondingly higher costs. This may discourage some potential code contributors, particularly young people, from becoming programmers.

Of course, I don't know who else will prefer desktop and laptop systems or where the market will go. But SaaS provides a solution to the problem, if indeed it becomes a problem: services can offer their source code on sandbox systems with interfaces to let developers play with the code and test changes. A cell phone may be an inappropriate input device, but a netbook might suffice. Contributing to free software will be like using Google App Engine. And free software can join SaaS as a first-class citizen.

Is participation going down?

A European free software advocate recently told me that the number of developers in free software seemed to be on the decline. Other people I've talked to about this subject said they see no evidence of this. But I could imagine a few reasons that people might find other distractions and spend less time coding:

  • There are other cool things to do online: multimedia, blogging, participation in social networks, and now even input into government actions (see my recent series on open government). Whereas programming used to be a unique way to share creativity with people around the world, digital media and networks now grant wide influence to many other pastimes.
  • Programmers are tempted by Software as a Service, which offers an even faster and more convenient way than free software does to expose functions to the public. I bet a lot of the people developing SaaS sites here at OSCon would be developing free software packages for download a decade ago (although many still do that in addition to SaaS).
  • Most big, popular projects have come under the patronage of corporations, who provide the bulk of the programmers out of their paid staff. (Of course, many projects also take the opposite path, originating in a corporation and winning over a large volunteer community later; Eclipse and Firefox are examples.)

If some professional researcher released data showing a decline in the number of free software programmers, these are reasons I would offer. But I think voluntarism in free software is still vibrant. It seems like releases are coming faster than ever. And every week some project developed by an inspired individual hits the newswire.

Design by Damian Conway

I went to Damian's talk "7 Principles of Better API Design" because I figured his principles would extend beyond the Perl that he has so stupendously mastered to other languages and contexts as well. No, actually--I went to Damian's talk because his talk are always fun, but additionally I hoped his principles would extend beyond Perl to other languages.

In some ways they do and in other ways, I think, they don't.

Some of his recommendations resonated with fairly standard practices (for instance, intercepting function names or arguments and using introspection to add functionality). Some may be just a fun way of restating principles other people have established (for instance, "Do one thing really well" and "Evolve by subtraction" mirror the ruthless modularization used in modern designs).

However, "Evolve by subtraction" also includes the surprising advice to wait at least one release before providing defaults. Damian told us to require programmers to supply all parameters, watch what most of them pass after the API has been in the field for a while, and then make the most popular values the defaults. (This includes adding convenience functions.)

We begin to see here a hint of Damian's galvanizing philosophy. Most of us idealize API design as something that grows organically from the seed of a brilliant idea--the design as a consistent, coherent, and elegant expression of the designer's view. There's coherence and elegance in Damian's creations too, but they start from the outside (how people use the API) and move inward.

The ideal API to Damian embodies a "do what I mean" naturalness. The only way to give your programmers "do what I mean" is to find out what they mean. There are several ways to do this:

  • Ask them. This is the strategy exemplified by deferring the choice of defaults.
  • Look at what they've done elsewhere. For instance, make a logging interface look like a garden-variety print statement so programmers can send messages to logfiles using the same interface they're accustomed to using for printing strings to the terminal.
  • Look at the way people's minds naturally work. For instance, provide a regular expression interface that lets people specify "int" instead of "/[+-]?\d+/".
  • Get rid of everything you can. Whatever can be gleaned from the environment and routinized should be encapsulated in under-the-table implementations. It doesn't matter how ugly and convoluted the implementation is, so long as the usage on the surface is easy.

Very appealing, all of this, But there's a point where Damian's philosophy betrays a Perlish way of doing things. This includes:

  • Prioritizing simplicity and usability over consistency with other parts of the system (although, as the logging example shows, Damian sometimes finds clever ways to increase consistency). There's a frolicsome sense of bending the language to immediate need. This same impulse lies behind domain-specific languages, which are popular at the moment, but domain-specific languages seek out a new consistency that hides the underlying system rather than sitting side by side with it.
  • Growing without limit. Damian's maxim is that every API fills a deficiency in the language. It would be best if the language did it for you, and did it right, but when the language doesn't you should add extensions to offer what you want. This attitude is endemic to Perl.

Still, Damian's axiom of letting the programmer do what comes naturally and augmenting that behavior in convenient ways strikes me as much more appealing than frameworks that just set defaults and require you to use their conventions, especially when the conventions arbitrarily determine that one version of a name is lowercase, and another is init-capped, and another is pluralized, and names from related modules have to be combined in a certain order, and so forth. I do believe that Damian's seven principles should be at least taken under consideration by everybody who designs an interface.


You might also be interested in:

4 Comments

I'm not sure that SaaS actually hurts Free Software. The potential is there - but there is also great potential for Free Software. Imagine 100 companies using SaaS on the same platform... like, I don't know, maybe a CMS such as Drupal. In fact, exactly like that. A content management system is 'SaaS'. But consultants and developers get paid to change some things for clients... sure, the modules may not make it back to core...

But the idea typically will.

So there's a lot of parallel development going on, and the evolution of the code is paid for through customizations... and ideas found on those customer paths find their way into the code, increasing its allure. And as a CMS becomes more standard, people want it to look less and less like a standard CMS...

So yes, I think it could work. I'm pretty sure it does. :-)

Andy, I can see your point regarding SaaS, but I don't want to believe it. I remember having similar discussions back in the 90s when the web started to explode, and everyone worried that all those new users and their demands would stifle open-source creativity. What happened was that, while the number of users did indeed explode, the number of developers went up too. New developers naturally gravitate toward the best and cheapest tools. In the case of open-source, those are generally the same thing.

At this point in history, the growth of any technology will advance open-source software, probably at a faster rate than closed software. I think Microsoft's very recent advances into GLPv2-based code sharing are evidence that they acknowledge the success of the open-source model. The growth of mobile devices and other thin clients that use SaaS will only increase the demand for more developers and better software. I believe that more and more of that software will be based in open source. Historical data seem to suggest it.

One of the original goals of Free Software was the enable the user, to let the user have control.

The SaaS model might be a big problem, if people don't control their own data anymore. If it's based on Free and Open Source Software it might help, because atleast the file-formats are probably known, but still, it might just turn out to be an other way of lock-in.

Does anyone remember tha Affero General Public License? Under tha AGPL, a SaaS provider must provide the source code. This fixes the first SaaS problem as there is no dobut that more FOSS will be licensed under the AGPL as SaaS becomes more widespread. Then it is likely that current FOSS hubs like Googlecode, Sourceforge, and Github will allow more development services than just hosting; like code editors, compilers, and virtual machines. As we move to thin OSes (think ChromeOS) desktops will still exist for work that needs a full set of user interface hardware. So the future of FOSS is still as bright as ever.

News Topics

Recommended for You

Got a Question?