On speaking in URLs

December 3, 2010

speaking-in-urls-2.jpgI’ve seen about five examples just today where speaking in URLs (I spoke about that before, slide 27) would have saved people from misunderstandings, and avoided wasting our collective time.

When writing about something that has an URL on a project’s mailing list, for example, pointing to it precisely makes a big difference. You will save people’s time, avoid misunderstandings and over time create a goldmine of linked information on the Web. It’s not a web without links, ok?

Writing https://issues.apache.org/jira/browse/SLING-931 (or at least SLING-931 if that’s the local convention) is so much clearer than writing about “the jcrinstall web console problem”. You might know what the latter is right now, but how about 6 months later when someone finds your message in the mailing lists archives?

Of course, all your important technical things have stable URLs, right?

Twitter is the new CB…but it’s missing the channels!

September 29, 2010

When I was a kid, Citizen Band Radio (aka “CB”) was all the rage if you could afford it.

Those small unlicensed two-way radios have a relatively short range, actually extremely short if you compare to the global range of Twitter today. And they don’t have that many channels, 40 in most cases if I remember correctly. That works as long as the density of CB users is not too high in a given area.

For general chat, CB etiquette requires you to start by calling on a common channel for whoever you want to talk to, and, once you find your partner(s), quickly agree on a different channel to move to, to avoid hogging the common channel.

That “agree on a different channel to move to” feature is key to sharing a limited medium efficiently. As the Twitter population grows, the timeline that I’m getting is more and more crowded, with more and more stuff that I’m not interested in, although I’m willing to follow the general flow of a lot of people.

The global reach of services like Twitter and ubiquitous Internet access makes CB mostly obsolete today.

Twitter is the new CB, in many ways.

What Twitter lacks, however, are the channels, as in:

Could you guys at SXSW move to the #c.sxsw channel and stop boring us with your conference chitchat? We’re jealous, ok? Thanks.

Direct messages don’t work for that, as they are limited to two users. A bit like a point-to-point channel, like the telephone, as opposed to multipoint as the CB provides.

Twitter channels can also be very useful for data, like weather stations or other continuous data sources that can benefit from hierachically organized channels. But let’s keep that discussion for another post. Like my mom said, one topic, one post (not sure it was her actually).

What does Twitter need to support channels?

I think the following rule is sufficient:

Any message that contains a hashtag starting with #c. is not shown in the general timeline, except to people who are explicitely mentioned with their @id in the message.

Such messages can then be retrieved by searching for channel hashtags, including partial hashtag values to support hierarchies.

Using hierachical channel names by convention opens interesting possibilities. The ApacheCon conference general channel would be #c.apachecon for example, the java track #c.apachecon.j, etc.

This channel filtering could of course be implemented in Twitter clients (@stephtara, remember you said you were going to mention that to @loic?), but in my opinion implementing it on the server side makes more sense as it’s a generally useful feature.

Then again, I’m a server-side guy ;-)

Opinions welcome, of course.

This is how we work at Apache

July 16, 2010

I just had to (re-)explain how the Apache way of working makes a difference by enabling a continuous flow of information between developers.

No more begging for reports, no more boring meetings where you only exchange information: who could say no to that?

Here it is for your enjoyment. This is the same thing that I’ve been saying in my recent talks on this topic, reduced to the bare minimum.

  • All technical discussions and decisions on public mailing lists.
  • Speak in URLs: if you reference something (discussion, vote,
    code…anything) include its URL, which must be permanent.
  • Shared code repository, commit early, commit often (as in: daily at least, from day one)
  • Commit events sent to mailing lists and/or RSS feeds to which people
    can subscribe.
  • Shared issue tracker and “if you’re working on something it must be
    an issue in the tracker”
    so that progress reports are automatic. Also generates mail/RSS events.
  • Commits are linked to tracker issue IDs – by speaking in URLs in your commit messages, mostly.
  • Automatic archiving of all this information, for self-service access.

All this is public and centrally accessible of course, so everybody
gets the same information.

The main reluctance that I see when trying to convince people to work
in this way is the fear of exposing your mistakes and initial bad
designs in public. My answer is to just get over it: you’d find tons
of such blunders if you were to analyze my work at Apache in the last
ten years, yet I’m reasonably alive and kicking.

Can I haz web?

June 15, 2010

How many people today still think information is only valid or “serious” when represented on an A4 piece of paper?

Way too many, if you ask me.

I’m always disappointed when people push out important content as PDF documents (or much worse…I won’t even name that format) attached to web pages or email messages, instead of just including the content in those web pages or messages, as a first-class citizen.

For some reason, people seem to think that information presented in A4 format has more value than the same information presented as a simple and clean web page. It is quite the opposite actually: web pages can be linked to, easily indexed, reformatted for efficient reading (thanks readability), etc.

Ted Nelson, the inventor of hypertext, wrote in 1999 already [1]:

We must overthrow the paper model, with its four prison walls and peephole one-way links

And also, in the same paper:

WYSIWYG generally means “What You See Is What You Get” — meaning what you get when you print it out. In other words, paper is the flat heart of most of today’s software concepts.

Granted, we haven’t fully solved the two-way links problem yet, but I hope you get the idea. Who needs paper or A4 pages? This is 2010, and this is the Web.

Please think about it next time you publish an important piece of information. Does it really need to live in the prison walls of a “document”? In what ways is that more valid than a web page or plain text email message?

Most of the time, almost always, the answer is: it’s not more valid, it’s just less usable.

Can I haz web? kthxbye.

[1] http://people.artcenter.edu/~vanallen/web_techniques/tednelson_liberate.htm

The single mailing list dream

June 13, 2009

The ASF uses a (way too) large number of mailing lists for all its internal and project communications.

Having crosscutting discussions is quite hard – for example, many projects use OSGi these days, and the only way for them to share their OSGi experience would be to create yet another list, or to subscribe to all of each other’s lists, which means a lot more traffic to manage.

One of my current technical dreams is to have a single list for all of the ASF, using tags to define the audience and visibility of messages – a la Twitter hashtags.

A message about the maven-scr-plugin on the Sling list, for example, would be tagged

#sling #osgi #maven-scr-plugin #scr #public

so that people subscribing to the #osgi and #scr tags, for example, would see it.

Another obvious use case is to easily ignore all discussions about a given topic (like #budget maybe? ;-), in a reliable way and without losing other communications within the same group.

I’m not sure how to implement this today (particularly the access control part for things like the #asf-private tag), but that would in my opinion be a huge improvement on what we have now.

Update: it’s now 2017 and I heard from a colleague that his company the OpenStack dev list is using this model for group communications. That’s using mailing lists, but the model would apply to any shared channel that supports threaded discussions with searchable thread titles. I’m so happy to hear that this actually works! And too bad I haven’t been able to use it myself so far.

Open Source Collaboration Tools are Good For You! (really)

April 10, 2008

Really? Well my talk at ApacheCon is done and went well, so that’s real at least.

Someone commented that it was good and depressing at the same time. Their company has all the tools in place but doesn’t get any added value, due to using them in the wrong way, or not consistently enough. Good to hear that my talk at least maps to real life ;-)

Moving from the previous talk‘s bare metal approach to a higher level “what are the real issues that we’re solving” approach was a good idea – people are aware of our tools today, we don’t need to explain what they do as much as before.