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

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.

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.

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.

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.

Tags:

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...

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?

Do you have a question about O'Reilly's products and services? Share an idea! Report a problem...