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
- Is participation going down?
- Design by Damian Conway
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.