Bosphorus Web Services and an open source communication layer for openEHR implementers

Technical (archive)
21

Torvalds even said that he passionately hated CVS, which he had to use
at Transmeta.

I feel the need to explain why open source is important (this is not
ideology), and the CVS/Bitkeeper/Git story is a good example to explain it.

If you don want to read, just skip this message.

The Linux kernel-development used Bitkeeper instead of CVS and for good
reasons, but they also stopped using Bitkeeper for good reasons.

The reason why they stopped using Bitkeeper and went to GIT is because
the conditions for using Bitkeeper suddenly changed very radically on
account of the opinion of a single person, the owner of the product,
Larry McVoy.
He accused Andrew Tridgell to have re-engineered the Bitkeeper protocol.
McVoy started as penalty for this, asking money to the Linux development
team.

My opinion is that McVoy wanted a piece of the money-cake that goes
around in Linux, and he tried blackmailing the project, and I think that
the re-engineering story just was a pretext to do so.

So Bitkeeper was good, but had the typical closed source disadvantages.

This was unacceptable for the Linux-kernel development. So they started
to create a new product, called GIT, which is very much alike Bitkeeper.
The difference is, GIT is an open source product.

Why would that be?

It is not because of the money, IBM, RedHAT, SuSE are able to pay for a
product. The main reason is, the Linux Kernel development must not be
depending on a single person or company. That is too dangerous.

You can call it ideology, but it is pure practical business way of
thinking. I wouldn't call IBM a company which keeps ideological
principles, than just one, and that is how to make the shareholders happy.

Having an open source product as version system is the only way
companies can work together and keep on trusting each other.

Open Source is not just a funny feature of Linux, because of some
ideologists want it this way. It is the only way why it can exist, and
compete with closed source products, like from Apple or Microsoft or the
many UNIX-vendors in the nineties.

Ask yourself why Apache has half of the market-share. And why IIS, the
product of Microsoft the number-one software vendor in the world, for
over ten years cannot reach the half of its market-share.

The main reason is not quality. I think Microsoft is able to write a
good webserver. The main reason is because Apache is open source, and
therefore public domain. No-one can require for funny demands to use it.

Bert

22

Lack of backwards compatibility was just an example of important issues
that can come up in software. Also in open source.
But very often it happens in closed source, as vendors see it as a way
to push customers towards new versions of their products.

23

Hi!

The main reason is, the Linux Kernel development must not be
depending on a single person or company. That is too dangerous.

I think this "dependency" is one of the key things to consider
regarding openEHR too.

When it comes to version control of software I don't think it it would
be a _huge_ problem if we used a free commercial solution in the
cloud. If they start giving us trouble we simply move the code
elsewhere. It's still a problem though since we might lose the old
versioning history of the project. Tagged releases could be kept as
zip-files of course, but the continuous history is lost. Git is
different, everybody that wants it can have the complete digitally
signed tamper-proof versioning history. There is technically no single
central point of of control in GIT (even though you can socially set
up your project to work in a centralized manner regarding release
related branches etc if you wish). Thus if we use a commercial Git
provider like Github we could move elsewhere without losing versioning
history.

But again, regarding software up to now we have not had many
independent branches and most important design discussion and
announcements are facilitated out-of band in mailinglists rather than
via the versioning control comments etc so losing version history
might not be too disastrous.

Regarding archetypes on the other hand most discussion is nowadays
done in the combined CKM versioning & discussion tool, so losing
history from that combined repository would be a very bad thing. So if
we would be using a version control system as underpinning for a
future CKM alternative or for some kind of archetype "nursery", then I
think Git would be the very best way to go. Everybody that wanted a
copy could of the complete history could have one and you could in a
controlled manner at the same time follow and reintegrate development
work from local/national efforts etc. If we at the same time could
integrate the technical backend of the clinical
discussion/communication regarding the archetype development too it
would be great. (That does not mean that clinicians would be forced to
understand GIT - a clinical frontend GUI could be similar to the CKM
or whatever.)

So some suggestions:
- Let each software project pick their own versioning mechanism, but
perhaps try to agree on hosts, e.g. use cloud-service X for SVN and
cloud-service Y for GIT so that developers involved in several openEHR
projects don't need to register accounts in too many places
- If any future functionality (like CKM++) is BASED ON a versioning
control system (rather than just using one) then make sure it is open
source and that complete history is not only kept at a single point.
Git would seem to be the obvious choice here.
- If a unified issue-tracker service could be used for all projects
then that would be preferrable. Also here it is important to use an
open or decentralized system so that the issue tracking history does
not get lost if a commercial service changes terms or goes bankrupt.
- Regarding dependency and vulnerability I also think it's important
that (as in the Apache organization) every openEHR board and
sub-project has members or "committers" from at least three different
economically independent organisations.

Best regards,
Erik Sundvall
erik.sundvall@liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733

24

One point I'd like underline explicitly is: let us stay away from the
management of an actual server if we can. All the discussions so far
seem to imply this, but I wanted to express this clearly.
Regardless of what we choose, if we can avoid having an actual machine
to take care of, we'll do much better. It does not matter if it is a
virtual or real machine, there will have to be security updates,
software updates etc. It is much more efficient to consider this
aspect of running the tools as infrastructure and delegate it to
whatever provider we use.
Unless someone thinks we need to have full control of a server, let us
go with a set of services, and leave the management of server to
hosting provider.

I think we need to distinguish between collaborative tools for wiki,
CKM, web site, SVN etc and development infrastructure. Build servers,
or a server for some web services should not be handled on the same
infrastructure with the collaborative tools. I think that is a
different discussion.

Kind regards
Seref