Away from iphone and towards a better platform analogy

As many of you know, the CHIP/Indivo/Harvard guys (who I guess I should call the ITdotHealth guys) wrote an article in the NEJM saying that we needed something like the Iphone app store in Healthcare IT.

I wrote a rebuttal saying that, among other platforms, the Google android platform was a better fit. Frankly, I thought that would be the end of it. Most of the time I write a blog post, I get some hits, and maybe a comment if I am lucky. But mentioning the iphone is great for getting attention. Apparently, just saying the word iphone brought the readers out of the wood work. iphone iphone iphone <- (just to be sure…).

More than just getting some good comments I have just realized that Ben Adida (check out my blog roll) wrote a Knol that touched on my criticisms and argues convincingly that there needs to be some balance between openness and safety.

Though it is clear that Apple’s regulation of the iPhone apps market has gone far beyond malware prevention, the goalof malware prevention is certainly reasonable.

I think he is right on, and I look forward to talking about it with him in person tomorrow. I think now, the night before the conference, it might be a good time to drop my thoughts about what platform analogy would really be the best to reference as we move forward. I also take a moment towards the end of the post to concede some of the things that Apple really got right, since I do try to be fair.

If I had to pick one thing that best embodies the 10 principles that are being targeted here, I would pick yum. Yum is the update manager for Red Hat based operating systems. Here’s why:

  1. Like the iphone app store, it is “substitutable (first of the ten points). You can download like 10 different web browsers on the current Fedora.
  2.  It built its own protocol. RPM was a lower-level standard, and yum was born as a meta-tool on that standard.
  3. Yum allows for multiple platforms. It forms the basis for the software packaging for just about every Red Hat/Fedora based operating systems, of which there are several.
  4. The API for yum is open, which is what lets things like yumex happen.
  5. The programs installed by yum never have direct control over yum (unless that is the point of the program, and that is what the user wants to do).
  6. Application install is as pointy-clicky and as user friendly as it gets BUT you do not lose the power of command line script-ability. Talk about walking the fine line!!
  7. Separation between the copyright/patent/trademark of applications and the platform is totally there! You can point your yum to a proprietary repository, for instance to download Adobe flash… no problem.
  8. Unfortunately it does not make any sense to say that you can remove everything from yum and still have a platform. So I guess it strikes out on that one. Of course, I am not sure why the platform itself should -not- be considered a package on the platform… Ill have to ask about that tomorrow…
  9. Yum is really really efficient. You can update applications very quickly, and you can even install a special yum module that will find the fastest download servers, ensuring the best experience for downloads.
  10. The certification is as minimal as can be. The packages -can- (not required to be) signed by the people who set up a repository, and you simply do or do no trust that signature.

Someone will point out, someday, in comments that apt-get is just as good and does all the same things. To that future commenter I fully admit that you are 100% correct. I am a long time Red Hat guy and I am letting my colors show, for the record I am trying Ubuntu on my desktop for now….

Now let me point out a couple of cool things about yum that are not on the “big ten” but that I think are worth emulating:

  1. Yum is actually an upgrade to a previous platform, Yup. Yup was good, but users forked it and made it much better… then the original yup developers adopted yum. That’s the virtuous cycle of Open Source in action if I have ever seen it.
  2. Yum handles “trust” in the system, by getting out of the way. A “default” repository is trusted to get the system off the ground. But you can “trust” other repositories to get upgrade versions of the software you are currently using, to get substitutionsfor the programs you were currently using, or to get new software that is found nowhere else. It automatically find the balance betwen openness and security. Users make the decision about how to trust, and the system does not auto-branch beyond those decisions.
  3. Although yum violates principle 8,  you get the benefits of being able to use the platform to upgrade the platform. You can upgrade a late-generation yum operating system while it is running.
  4. The yum platform was central making a larger community effort. Remember when Red Hat stopped doing Red Hat Linux, instead creating the Fedora project and RHEL? Fedora existed before that, as a high-quality repository of Red Hat packages! yum was an important new feature of Fedora Core 1. The yum platform helped move the whole community forward.

So I think the yum project and the way that Red Hat made into a software distribution network is a pretty good model to follow.

Even I, however, get why they original authors chose to use the iphone as an analogy. Not assuming that these points are original, I want to point out some things that Apple did right, that other systems have failed at.

  1. Apple enforced simplicity. They refused to allow programs to run in the background. They refused to allow many other things that a developer for Windows CE might have expected. They made the core interface as simple as possible. They even excluded cut and paste initially to make the system simpler. Apple put these restraints in place because by making the applications simpler, they made the user experience vastly more intuitive.  I have used countless “modular” or “substitutable” platforms that miss this.  It is the platforms responsibility to protect the overall user experience, -not- the application developers. That means knowing when to say no. Ignore this one at your peril.
  2. Apple built a meritocracy at the level of the end user. When you see an application on the iphone that has been used by 5000 users, and they have all rated it 5 stars, you can be pretty sure it is good. That rating stands front and center in the platform, and more importantly, the platform itself constantly promotes and rewards its star performers. On other modular systems, I usually spend a lot of time trying to sort out what modules are reliable. The Firefox module system has also done a good job of this.
  3. Despite its habit of blessing particular development groups with special privileges, Apple also made it easy for the individual developer to become a super star on the platform. It did that by giving people pretty substantial development tools and a robust development environment.  If you want to get rock star developers you have to give them their version of the red carpet. That means awesome documentation, video tutorials and lots and lots of working examples.

I figured I would jot down these thoughts before the conference, so that I can have the most fun while there. Apparently, some of these people are actually reading this… so its a very efficient way of making points as opposed to taking the whole conference to dinner with a Fred-monologue.

-FT

Health of the Source

I pretty regularly give a talk entitled “The health of the source”. The subject of the talk is everything that has happened in health FOSS, since the last time I gave the talk. Thankfully things move along fast enough that I am never short of content. You will find this article dripping with useful bias and opinion. This is not merely a list of projects but also what I think of the projects. I might be omitting your favorite project intentionally, because I think it is irrelevant, OR out of ignorance, OR because I am limiting the scope. For instance this time I did not include much on clinical research (openclinica) or imaging, since my TEPR audience might not be interested in those.

This intended to reference Larry Walls regular summary of the perl community typically entitled “state of the onion“. (I am suffering from pun envy here… if you have something better… let me know) As I was writing yet another throw-away Open Office presentation, I was lamenting the fact that I had not posted anything really meaty on my blog lately, and I thought I should post my presentation. Then I was thinking how each page of my presentation would really serve as a blog post by itself. Then I realized that I could write one blog post, and if I kept each page short enough to fit above the fold on my little laptop, I could make a postentation. ( <- just invented this word)

So if you would like, you can now read my latest presentation just by clicking on the page numbers on this post. Hopefully it is coherent enough to read without me talking about each slide. But if not, leave me a comment and I will try and fix things.