Tuesday, April 25, 2006

Protective Colouration, Trademark violation, and NEC

Slashdot has an article today on how a group of people -- pirates, in some sense of the word -- have cloaked themselves in the coloration and name of the Japanese electronics corporation NEC and, essentially, established themselves as a rogue division.  It's like the relationship between the Monarch and Viceroy butterflies (note, even the names imply the relationship!).

Monarch caterpillars feed almost exclusively on milkweed, which is more than mildly toxic and correspondingly foul-smelling and -tasting to mammals and birds.  The toxin stays in the insect during its transition from caterpillar to butterfly, so Monarch butterflies taste *terrible*.  They adopt a protective colouration that's a bit counterintutive as a result -- they're orange and black, with somewhat stripy patterns.  Google's image search will give you a really good idea.

Viceroy butterflies are a different species altogether, with a much wider diet.  They eat some milkweed too, but not nearly as much as Monarchs do -- so they don't taste particularly bad, as insects go. However, their colouration is very similar to a Monarch's. They piggyback on the reputation that Monarchs establish, and are predated less as a consequence.

If you've read the Slashdot article, you know where I'm going here.

The term we use to describe what Viceroys do when companies do it is "trademark violation".  Of a particularly egregious sort, because it applies both up and down the supply chain.  It's piracy, but it's a twisted kind - misrepresenting your goods to consumers is one thing, but misrepresenting your business to your suppliers requires even more cojones.  I can't help but think that we'll see more of this, though, and that biological metaphors will take us further and further toward the realization of a true business ecosystems.  Here's a prediction for you: the other component required of the global market to create a true business ecosystem is autonomous corporations.  Give it 10 years.

Friday, April 21, 2006

Charlie Stross goes deep, hoping to catch his own Hail Mary

In his latest post, Charlie Stross (who is one of my favourite Science Fiction Writers) sounds off on his craft in a deeply technical way.  The second last paragraph in the post contains this gem of writerly jargon, fit for publication in almost any lit-crit journal:
It's not so much about metafiction as about metainformation for the fiction at the centre of the narrative process. [italics his.]
WOW.

Tuesday, April 18, 2006

It's going to end up custom anyway

The Anti-WS-DeathStar* movement's been pretty active lately, at least in the corner of the blogosphere I read.  Although I really do agree with them -- I think time spent on WS-* would be better spent elsewhere -- it was only this morning that I think I finally nailed down why.  Being as deeply ensconced in an architecture-oriented environment as I am, I can certainly see why WS-* exists, and I think that there's nothing malicious about WS-Consortium's attempt to WS-Standardize the world.  The problem is that it's all founded on the assumption that all the WS-Work will lead to WS-Specifications that are complete enough that different implementations will be interoperable. 

And I think that's just not the case.

Every implementation of a specification has different characteristics.  Even when two implementations conform exactly, there are differences -- perhaps in memory usage, perhaps in run time, perhaps in the relative efficiency of two (or more) operations.  And that's assuming that the spec is unambiguous (or that the implementations interpreted ambiguity in the spec in exactly the same way), which they often aren't.  So ultimately, there has to be some change, or some custom code, to connect two implementations of a spec.

So why not make it as simple as possible to make those changes?  The more statements a spec has, the more places there could be error either in specification or in interpretation.  Conversely, the simpler a spec is, the easier it is to implement correctly.  I'd rather have many small specifications to implement than a single large one -- after all, they're all going to end up custom anyway.

Thursday, April 06, 2006

lessconfig is another word for friendliness

Jaime wants to know "why lessconfig?".

1) Because I'm not special.  (the defaults should work for me until I have a reason to change them.)

2) Because I don't want to need to know how my software works in order to use it.  (I already know you're smart, I downloaded your program; you don't need to show me how smart you are by showing me how hard it is to get the app working.)

3) Because configuration is neither user- nor developer-friendly.  (Everything I can touch is something I can break.)

The first reason is the sensible-defaults argument.  I think we're all in agreement about that.

The second reason is a little harder for developers (myself included!) to grok because we like it when our work is appreciated, and because showing off comes naturally.  "This was hard to write, it should be hard to understand" is the ha-ha-only-serious expression I'm fighting here; we need, as developers, to learn to take pride in Just Works even if it means that our effort is misunderestimated by nontechnical people.

The third reason is the kicker, though.  The Mac users out there already understand this, and have for a long time.  The more configuration your app has, the smarter your users have to be.  Being smart is hard, but that doesn't make it a virtue.  Being smart is a (sometimes necessary) evil.  Anything that


forces me to think -- as a developer or as a user -- when I could just

be getting on with my day is Bad.  The more things I have to pay attention to, the more mistakes I will make when I don't.  And "just do your job!" is a wonderfully pragmatic thing to say, but given the choice between a package/patch management system that lets me hit one button and trust my machine is updated and safe and one that requires me to care about, and spend time on, each individual patch and I know which one I'll choose.