Blogging seems to have all grown up, gotten serious, and become a business tool if BRW is this week (27/05/2005) reporting on business blogging and its effect on modern marketing.
Apparently it is the saviour of marketing (according to a marketing person), which will only be the case when marketing understands how it works and what the message really is.
If ever there is a topic you need to know about, the web’s free encyclopaedia will likely have the answer for you: en.wikipedia.com
If you read up on how Wikipedia works, it seems anarchistic, it seems strange, and it seems somehow machiavellian in the extreme, but there is no doubt that it works. With all those authors contributing and, hopefully, not making stuff up, the peer review process means that it covers Fox Terriers to Robots with equal aplomb. However, when it is confronted with a contentious topic, it can all get a bit out of hand – as the Terri Schiavo entry’s history shows.
At the presentation on Tuesday night (on the commercial issues of Open Source software) I was asked if it was possible to manipulate the Sourceforge rankings. Unfortunately the website was mostly down at the time, so it wasn’t possible to answer immediately.
However, I have taken a quick look tonight and note that the Sourceforge.net rankings are able to be manipulated if one wanted to do so, as the formula is quite clear. However, as Sourceforge.net notes, those statistics are not the only way by which a project should be assessed. The ranking statistics are a good indicator of the project’s activity level rather than the quality of that activity.
The point should be made that the incentive of an project author to manipulate the rankings process is fairly low given that, in general, the potential monetary gain would be fairly minimal.
So far this year I have been to see several clients to review their approach to information systems. Almost all have struggled with the in-house development of software – in many cases a lot of effort has been put into developing in-house software, and although it must have sounded like a good idea at the time, they have come to regret it eventually.
In my humble opinion (and I haven’t really researched this one too much yet) there are usually several factors that end up ensuring that it all turns to tears:
For my clients, I often say to have a Bex and a good lie down before you embark on an internal software development project. And if it still sounds like a good idea tomorrow morning, then you should see your GP (because those symptoms are still persisting).
It’s not that all in-house software development goes to hell in a handbasket, but it is awfully difficult to do internal software development well on any large scale, and to have the discipline and the methodologies available is often beyond the capacity of a lot of my clients here. If you ever do think about writing substantial amounts of bespoke software, be sure to recognise the risks that come with that approach.
I am beginning to wonder if you aren’t better off adapting sometimes an open-source solution that does 80% of what you need for a small commitment of work (and my presentation on Tuesday night, again, talked about some of the issues you might come across there).
Hmm. I suggest I’ll need to write an article on this topic one of these days. Although, maybe I just did that.
The presentation I gave on Tuesday night (regarding commercial issues with open source) touched somewhat on the legal issues around open source licencing, although not a great deal. I did, after all, only have an hour or so, and a legal issue is not always a commercial issue – until it all ends in tears and winds up in court, that is.
Part of my research found this paper on the web entitled “Open Source Issues in Business“, which looks at the legal issues of using open source in your business. It does have a US-law approach, which anyone in Australia will tell you is “interesting and unique”, which would not be a positive thing to hear if it was a first date. However, the US legal regime tends to want to impose itself wherever it can go, and is having a darn good go at it wherever a “free trade agreement” goes.
So, there it is – “Open Source Issues in Business“. It’s instructive to quote the conclusion for your information:
“Circling back to the two hypothetical scenarios posited at the beginning of this article of a company desiring to protect is proprietary software code and hoping to make a profitable distribution, and a company that simply wants to use open source software for its internal operations: in each case, the software may be “free†but free lunches usually come at some price and so does “free†or open source software. Both companies need to learn more before consuming their free meal, and to consider that various issues that we have discussed here.”
As always, feedback is welcome.