Using financial theory to explain Open Source

July 27, 2005 on 7:23 am | In Random | No Comments

This article on ONLamp uses financial theory to examine the difference between Open Source and proprietary software, concluding that:

Therefore, the major difference in worldview between open source advocates and proprietary software license advocates is explainable as a differing opinion on the correct value of the volatility of maintenance and upgrade pricing. People who believe that the pricing on maintenance is stable and unlikely to change see greater intrinsic value in the software. People who fear that the pricing is subject to large fluctuations see no intrinsic value in the up-front license; stripped of the options, the license value approaches $0.

For the open source movement, perhaps a better way to position the change that OSS is making is this: we’re converting warrants on future maintenance and enhancements into options, which means that instead of having a sole supplier (warrants), we have created a third-party market (options) of these derivatives.

What an interesting way to look at things…. and very powerful. What happens to Enterprise Software when purchasing departments begin to do these calculations?

Article on Open Data formats etc.

July 27, 2005 on 4:53 am | In Happenings, Industry, Preservation | No Comments

I am extensively quoted in this article in Scientific & Computing World on the importance of Open Data formats.

Oracle encryption: Ouch

July 26, 2005 on 10:04 am | In Happenings | No Comments

From this article:

The standard encryption mechanism used by Oracle’s (Profile, Products, Articles) database products can be easily circumvented, according to a German security researcher who last week published details on a number of unpatched security”

Ouch. Not what you want to see, bad for Oracle, bad for customers. Not strictly an ELN issue, but it is a good example of one of the reasons why I think you want a very simple, very boring, stand alone PECP (Patent Evidence Creation & Preservation) system:

  • Simple systems are easy to see if they’re working OK, so if there’s a problem you can see it quickly - and less specialist skills are involved.
  • There’s less to go wrong with a simple system.
  • Because the system is standalone and not used for other purposes, there’s less chance that unrelated “events” will compromised your patent evidence.

The business requirements of PECP systems are comparatively simple. The hard part is developing & deploying systems which are robust in the real world. That’s much harder, and it is much less of an IT problem than people think. In fact, a reliable PECP system will probably violate a whole load of “IT best practice”.

Next Page »

Powered by WordPress with Pool theme design by Borja Fernandez.
Entries and comments feeds. Valid XHTML and CSS. ^Top^