I'm not sure that I agree with a 200 year horizon, especially for a field that is less than 50 years old. However, I think that many of the issues that he describes in the article are important and worth thinking about. Foremost among them is the notion that a certain classes of software are societal infrastructure. While he doesn't use the terminology explicitly, Bricklin, argues that these classes form a commons, and because they form a commons they ought to be conceptualized, designed, developed, and funded differently than other classes of software.

I haven't worked on the kind of software that he classifies as Societal Infrastructure Software, but I think that there is a class of software, call it Personal Infrastructure Software, which plays a similar role for individuals. At the moment, my personal description of that class includes RSS Aggregator, web browser, text editor, e-mail program, address book, calendar, and program development environment. I think that instantiations of these programs form a similar commons, and that we're seeing that come about in various degrees via open source implementations, but there are still issues that need to be deal with. Probably the most important one is data format lock in. Close behind it would be the staying power of the various communities working on various pieces of that commons.