How Not to Release Software

A lot of us in the programming community have been looking forward to the first release of Paul Graham and Robert Morris’s “Arc” language, which Graham has been talking about for a long time on his widely-read site, paulgraham.com.

On January 29th, they finally released a first-draft implemention. Although billed as experimental and subject to change, it’s still something a lot of people will want to play with. Those of us who for whom programming in Lisp is a cherished memory, a kind of long-lost Eden to which we hope one day to return, are interested to see if Arc can become what we’ve been hoping for: a Lisp-like language that’s caught up to the modern world and that gathers enough developer momentum to flourish.

Unfortunately, the Arc web site, arclanguage.org, doesn’t answer the very first question most potential downloaders would ask: is it open source?, or as we used to say, is it free software? The site not only doesn’t say what license the software is released under, it doesn’t even state clearly that the software is open source! I finally downloaded the package itself and poke around inside to find out:

This software is copyright (c) Paul Graham and Robert Morris. Permission to use it is granted under the Perl Foundations's Artistic License 2.0.

Okay. So it’s open source, albeit under the least open-source of all the open source licenses. Sigh. I normally wouldn’t even go to the trouble of downloading the software to find that out, I only bothered because I was already quite interested in Arc.

I’d post on their mailing list a comment about the hidden license problem, but they apparently don’t have a mailing list. Instead, they have low-functionality web forums, and it looks like the only way you can interact with the community is through that forum interface. This is a pity: the thread is the fundamental unit of information on the Internet, and there’s no reason to force people to use one particular interface to access a set of threads. Perhaps some people like web forums, but others would prefer to access the threads via their mailreaders. If I have to use a web interface just to talk to a community, it makes me less likely to join that community, because I’ll start to associate participation with wrist pain. Let me choose my own interface, please.

Speaking of which, how about a bug tracker? Or any of the other tools that are now standard for open source projects? Some of the forum posts indicate that there’s a version control repository somewhere (using git), but the web pages don’t point to it, at least not as far as I could see. So those looking to follow development in real time will have to hunt around.

Given that the web site says “we’d like to encourage a sense of community among Arc users”, this is all a bit disappointing, and puzzling. It’s like they don’t actually want to build a community, which would be fine (it’s their project), but then why declare otherwise?

5 Responses to “How Not to Release Software”

  1. Ben Collins-Sussman Says:

    Ignorance. Malice. You know the quote. Time for the Big Cluebat.

  2. Karl Fogel Says:

    Well, they certainly aren’t stupid. I think they maybe just don’t have a lot of direct experience with open source (as participants, I mean, not users), and don’t realize what kinds of vibes their site is sending out.

  3. CruxOP Says:

    As a developer, I prefer forums to mailing-lists.
    I prefer forums to IRC.
    I prefer forums to contact boxes.

    Perhaps you prefer mailing lists but that’s just your preference, and shouldn’t be promoted as part of the dogma of ‘how to release software’

  4. CruxOP Says:

    Oh I do wish they’d put up a bug tracker. Implementing something on parc with python’s trac would be a good way to show off Arc as a langauge and benefit the community.

  5. Karl Fogel Says:

    Thanks, CruxOP, for the comments.

    I think there are many developers who prefer mailing lists; therefore, to make a project succeed, it’s best to offer mailing lists. However, I wasn’t saying anything against having forums! It’s great to have forums, but they should be bidirectionally gatewayed with mailing lists: same data, different presentations.

    If they offer only forums, I’m pretty sure they’re going to lose some developers.

    Now, if there were an RSS feed for their forums, that would at least make it possible to read them through an interface of the readers’ choosing…

    The point I’m trying to make is that both RSS and email are, effectively, APIs: once the data is flowing in those protocols, other parties can (and do!) whip up any interface they want to it. They’re not limiting. But most web forums don’t provide a real API — you’d have to screen-scrape or something in order to interact programmatically with them. In effect, this means that the only way to interact with a forum (or at least these forums) is via the one interface they provide to your web browser, where as you can interact with mailing lists via a choice of interfaces.

    So the dogma here isn’t “mailing lists are better”. It’s “APIs are better”. Mailing lists just happen to be an API for which many clients have already been written (those would be all the mailreaders out there, as well as the many mail< ->web gateways like gmane, etc).

    Sorry that I didn’t express that clearly enough in the original post.

    Totally agree with you about the bug tracker, of course.

Leave a Reply