I Really Don’t Know

Ashamed…

at how many of these I haven’t played with…

40 Downloadable Open Source Social Software Applications

Cause and Effect

For those reading outside of England…

We’ve just had the first run on a bank in 150 years - Northern Rock has been forced to borrow billions of pounds from the Bank of England. It’s been really interesting to watch.

But what’s really interesting is the discussion of blame. Here are the reasons why the Northern Rock went down according to their senior management:

• The Bank of England refused an earlier rescue loan
• Another major bank backed out of buying/bailing them out
• The wholesale money markets closed
• The BBC announced that they needed an emergency loan before they had an official comment ready

What’s notable about these are that they are not the reason Northern Rock went down. That’s plain and simple that they had an imbalance between how much money they had in deposits and how much they had tied up in non-liquid assets. This happened because there was an imbalance in priorities throughout Northern Rock culture that led to them being great at lending money and not as focussed on bringing it in.

The reason I find this interesting is that it ties in with other thoughts I’ve been having about root causes.

The things that the Northern Rock managers are bringing up in their defense are all things that didn’t help, and maybe if some or all of them had been different there wouldn’t have been a run on the bank - maybe.

We’ve been talking at work about why nobody seems to really effectively achieve code re-use and several reasons come up again and again. Deadline; too hard; component not good enough to re-use and so on.

But, as with Northern Rock, I think the main reason nobody really effectively achieves code re-use is because there’s an imbalance in priorities throughout our industry that leads us to be great at producing new functionality and not as focussed on sharing capabilities.

Technorati Tags: code reuse, software engineering

Open Data Licensing

Back at the end of September we finally got to the point of releasing the first draft of the Open Data Commons License. This is work I’ve been involved in since Ian’s first draft of the TCL about a year and a half ago.

It’s great to see this license come to fruition, having argued about the need for this more than once.

It’s interesting to see the conversation happening around LibraryThing’s Common Knowledge and the Open Library project. Both of these are collections of factual data, I’ve been speaking to people involved in both and both have a clear desire to protect the data and ensure that it’s available for the community into the future.

Licensing is critical to that - as I said in Banff (listen) at the start of the year.

Back then we were concerned with navigating the difference in protection afforded to database in the EU and the US. In essence, databases have protection in the EU, but have no protection on the US. The reason we were looking at that was because the natural thinking goes something like this:

Creative Commons extends Copyright to allow you to easily position yourself on the spectrum of ‘All Rghts reserved’ to ‘Public Domain’.

Therefore Open Data Commons must need to extend a Database Right to allow to position your data on the same spectrum.

Well, the Open Data Commons license gets around that by being couched in contract law. This seems like a great way to license data for open use and prevent it being locked away in future.

With all that’s been going on then, it’s no surprise that I missed the Model Train Software case that could have a big impact on how Open-Source software licenses are drafted. A San Francisco judge ruled that the Artistic License was a contract - meaning that breach of the license did not necessarily mean infringing the copyright. That changes the legal redress and potential penalties available for breaching a license.

Interesting.

Technorati Tags: licensing, open-data, open-source, opendatacommons, law

Spolsky on VBA for Mac Office

Joel’s talking about Microsoft’s withdrawal of VBA in the Office Suite for Mac users.

Joel starts by explaining why VBA was strategic for MS:

However, it was seen as extremely “strategic.” Here’s what that meant. Microsoft thought that if people wrote lots and lots of VBA code, they would be locked in to Microsoft Office.

As Joel was on the Excel team at the time you’d expect this to be an accurate reflection of what was happening. It makes sense, Office is the big cash cow and always has been.

Towards the end Joel says:

they’re effectively making it very hard for many Mac Office 2004 users to upgrade to Office 2008, forcing a lot of their customers to reevaluate which desktop applications to use.

I’m guessing the outcome MS are hoping for is different; Apple have made great in-roads into compatibility with Windows, a lot of hard work of their own but also a move to internet and intranet approaches have helped shrink the gap. To the point where Macs are showing up more and more at conferences, in businesses and in homes. The removal of support for VBA on mac is unlikely to push mac users in business to run a different office suite, it’s far more likely to push their corporate overlords to move them back to Windows, or run Windows through Parallels or Bootcamp - either way MS get a mac customer back onto windows.

Sad.

Offshoring…

Over at Virtual Chaos, Nad’s been rambling about offshoring and outsourcing.

The problem though, is that writing code isn’t something you can translate into an assembly line. What I think the people pushing this type of outsourcing failed to comprehend, and seemingly still dont understand is that farming out development overseas doesn’t lead to innovation. … Someone famously once said every line of code is a design decision, I’m struggling to remember who it was [insert clever guys name here]. But that single statement embodies for me what the real problem is with outsourcing projects abroad.

I don’t really see this as about innovation directly. I think it’s all about design. There are plenty of software projects that aren’t about innovation; they’re about cost-reduction or about refreshing technologies (which is generally about cost-reduction) or about well, cost-reduction. Most of what IT departments in enterprise are asked to do is cost reduction - hence most of what enterprise will outsource is also about cost-reduction. Innovation isn’t really a factor.

The indirect quote that Nad references about code being design could well have been from Code as Design: Three Essays by Jack W. Reeves. Jack’s discussions parallel what Nad is saying; that writing code is the act of designing something, not the act of manufacturing something. “Tooling up” is done by the compiler and manufacture is when you press lots of CDs, or on-demand when folks download your RPM or MSI.

The answer you arrive at about outsourcing (and offshoring is just outsourcing with extra big communication barriers and some cultural differences thrown in) will depend on what part of the software universe you feel you’re in. For us, we write commercial software that we sell and maintain for a number of years, the quality of code is important.

But that’s not always the case for everyone. Say you have a legacy application that was not well-written to start with, it’s built on top of old, unsupported languages (say, Java 1.2?) and you need to keep running it with minor changes for a few more years. There is no innovation to be done. The design decisions in-the-small aren’t that important to you as they’ll be better than the ones made last time! Your team in the office are de-moralised by the very mention of the application’s name and you’re over-stretched on new projects that are innovative… Surely that’s a contender for off-shoring?

Worse is Better

Thom Hickey over at Outgoing posted a snippet about the old addage Worse is better - or “Crap is the new black” as I prefer.

Thom says:

People often accept this as the reason why VHS triumphed over Betamax, and why people use Microsoft products. <snip> In most cases it isn’t so much that one is better than another that is important, it is how broadly useful the technology is.

And here’s the nub of it I think. It’s not that one thing is absolutely better or worse, it depends on your criteria. That’s why [programming] language wars are so futile, languages are useful for what they allow you to do and how easy they make it. Nobody know why VHS won over Betamax for sure, it may be record time and licensing as Thom suggests, but it may be that VHS players were smaller and, hence, more discreet under the telly. Or it may have been that the VHS manufacturers offered slightly more opportunity for the retailer to make a few extra pennies.

Going beyond products, it’s about making sure your motivations and your customers are aligned. In the case of VHS, Mrs Miggins motivation is not to have a large ugly black Betamax machine in her lounge. She will, however tolerate the smaller VHS player. In the case of SGI it wasn’t that anybody said they didn’t like being able to render 3D teapots, it’s just that cost was a more important factor - the same was true of the original Sony transistor radio.

What’s key in our world, metadata, is to understand what it is used for, what can it be used for, what do customers want to use it for. Answering these questions can give us an indication of their motivations and can lead us to understand if our own motivations are aligned with them or, ultimately, in confilct.