The IEUC is pursuing the Grand Challenge goal of developing a new End User Computing Platform that will one day offer a true alternative to today's Unix, Linux, Windows, and Mac OS based systems.

By this we mean to suggest that future generations of these operating systems may one day be recast as instantiations of our new platform. Most of the work in the 1990's focused on moving towards cross-platform solutions, where cross-platform was taken to be the intersection of capabilities offered by the major platforms. As a result, End Users of such solutions were in effect limited to a subset of the capabilities of their platform of choice. Our new platform will offer a more rational superset of today's capabilities with an architecture that factors out what programs do from how they are manipulated.

In effect, we will be creating a meta-platform that will make the porting of software to any environment based on our work a relatively simple matter of defining how locally available controls invoke its core capabilities and how the data it produces will be displayed in the local environment. This approach is one facet of The Continuity Reference Model - the systems architecture that grew out of the Digital Library research in The Institute's prehistory.

Security is another key concern and we subscribe to the philosophy of Security Through Comprehensibility, with is to say that the only true source of security is the user's ability to understand what the code one is running is able to do. In effect, the platform should make it easier to ascertain the safety of third party code by providing a fine grained capability based security model whose policy decisions are under End User Control. We call this alternative to externally imposed Digital Rights Management, Fair Digital Use.

Thus End User Programming is one of our major research thrusts. To provide the best possible end user support it we are looking at integrating such approaches as software visualization, system-wide support for programming by example, and a "programmers apprentice" style mixed initiative dialog system to help end users script the system, debug code, and learn to use the full capabilities of the environment and its libraries.

We are also concerned with building a user community and creating economic models that will support the growth and widespread adoption of the new platform. This work falls in the areas of Innovation Management and Technology Transfer/Diffusion.

We feel that the next generation of End User Computing platforms needs to encourage its users to explore their full creative potential, support them in making socially acceptable use of intellectual property (the Fair in Fair Digital Use), and invite them to be good citizens. It should also inspire developers to create stable, extensible, and bug free products. These goals require an integrated approach based on a mix of technology and social incentives that we call Applied Captology.

Material in this meta-page will reflect these programs areas.

The Institute is interested in a broad range of research topics, but one theme unifies them all — our commitment to doing the right thing by keeping an eye on the big picture.

The Big Game

The sad reality in all too many corners of the research community is that Job One is winning grant money and Job Two is publishing papers regardless of how trivial a contribution they might make. Unfortunately, the best way to achieve these goals is to noodle around the edges of big problems and focus instead on short term projects with numerically quantifiable results. If one writes a paper on a big topic or proposes too radical a departure from one's last successful grant application, one's chances of success greatly diminish. So if an interesting question arises while running an experiment, it will be ignored (even if it could be directly addressed at the time with negligible added cost) unless its solution had previously been identified as one of the project's evaluation metrics. Moreover, unless a government or foundation can be found to sponsor the work, it will never be addressed, regardless of its long term import. If a line of research is about to bear fruit and a researcher has a choice of abandoning it because its current funder has shifted priorities or hunting around for a new funding sources, in all likelihood it will be abandoned. Given a choice between organizing a conference where a small number of participants will seriously exchange ideas and chart a new course for future research or setting up a gathering where several hundred papers will be delivered on six or seven parallel tracks so each speaker has less than ten minutes to present his or her idea, it is this later design that will be chosen.

Likewise, if an idea seems to hold too much potential practical value, we dismiss it as being something appropriate for development by the commercial sector even though we know that venture capital markets are highly unlikely to support it on the assumption that some big multinational player will come out with it first and capture the market or threaten to sue them for an Intellectual Property Rights Violation. So the best game playing strategy for the High Tech Start Up is to seek to be bought out by a larger player to conduct in-house research that will never see the light of day. Of course, the net result is continued stagnation as evidenced by the level of bugginess and frustration experienced by End Users the world over since the status quo is more than profitable enough for the biggest producers of today's products.

Academics don't like to talk about such issues, but this is The Big Game that has, for far too long, distorted our priorities whether we work in academia or industry. Most of us recognize the problem, but as individuals we are helpless to do much about it if we want to find jobs and resources to support our students.

A Matter of Systems Thinking

This is not to say that no one is doing serious or meaningful work, merely that the aggregate result of each participant's efforts to do right by their stakeholders leads to unintended system level consequences that reinforce the status quo to the detriment of End Users. In effect, while good work is no doubt being done, far too many resources are wasted in the pursuit of the elimination of just such waste — making it nearly impossible to get the best ideas and technologies into the hands of ordinary people, to whom they would make the greatest difference.

Thus when funders try to guard against fraud and strive to maximize the public benefits derived from their grant-writing actives by looking for hard short term quantitative evaluation metrics (published papers & data sets, dollars spent, head counts served), researchers and charities respond by avoiding riskier long-term projects and shifting their priorities to more short term or more readily quantifiable work. When venture capital tried too hard to maximize its short term Return on Investment (ROI) as a measure of business success, entrepreneurs focused on playing the dot com bubble instead of building long term profitability. In such cases, taking concrete action to maximize the overall long term societal benefit of one's endeavor, takes a back seat to documenting the appearance of trying to pursue this goal.

We strongly recommend "The Fifth Discipline Fieldbook" by Peter Senge, Art Kleiner, Charlotte Roberts, Richard Ross, and Bryan Smith for insights and aid in recognizing and ameliorating these effects.

Our Strategy

In any case, we at The Institute for End User Computing, Inc. are committed to finding creative ways to end this madness and we need your support if we are going to succeed. That can take the form of financial backing to give us the independence we need to avoid being drawn into The Big Game ourselves; but it can also take the form of your ideas.

If you are a Researcher, Developer, or even just an average End User who hasn't seen the inside of a lecture hall in decades, we want to know what research topics and questions you think need to be addressed that aren't being addressed in the current academic milieu. We are interested in identifying projects that don't necessarily fit current funding models or that seem a bit too interdisciplinary or radical in their design to be safe bets.

We will list the best ideas here and if some are more general topics than concrete experiments, we will try to find research designs that would lead to making some meaningful headway. Then, we will turn to both The Public and Private Sectors for the research talent and support needed to make them happen.

As you think about your ideas, ask yourself how they would help advance the development of a new End User computing platform and how they can draw on multiple disciplines to enlighten and empower End Users. Then Contact Us so we can help get your ideas out to the world.

One of the fundamental misconceptions about The Institute for End User Computing, Inc. is that we are simply interested in the same sort of applied research that is normally undertaken in the commercial sector.

Nothing could be further from the truth since we are deeply committed to understanding the big picture and thus see the process of applying and integrating technologies to empower End Users as a core subject of Basic Research. This is the paradigm of Basic Applied Research — an introspective multi-disciplinary process of fusing technologies in a flexible environment free of commercial considerations to simultaneously advance technology per se while advancing the technology integration, transfer, and diffusion process itself — which all too often is given short shrift by both academic and commercial researchers.

As to the platform itself, it would have the following main design goals:

1) Have one guiding principle — that of empowering the end user.

2) Take the best open-ended enabling technologies and integrate all elements of the design (including hardware, the OS, and development tools) from-the-ground-up into a post-desktop-metaphor computing alternative.

3) Support interoperability with other systems via accepted data exchange standards with advanced hooks for Grid-based computing.

4) Offer radical tailorability with an expository programming paradigm, so motivated end users could fully understand, customize, and transform its behavior.

5) Provide fine-grained security so the platform would be safe from terrorist cyber-attack and well suited to use by the defense and intelligence communities.

6) Factor out common functionality to improve stability so businesses adopting it wouldn't have to lose the millions of dollars in tech support and lost productivity that the status quo is costing them each year.

7) Provide low level multilingual support so the platform can form a bridge for international collaboration by providing services to automatically translate source code between different natural languages.

8) Design in accessibility for the disabled so users who can't use a GUI will no longer be disadvantaged in the job market.

9) Provide modular extension hooks to create a market for both large and small developers to extend the platform at both the hardware and software level to create customized solutions for various vertical markets.

10) Serve as an interdisciplinary test bed during its ongoing development to create opportunities for graduates and advanced undergraduates at multiple institutions to work together with commercial sector colleagues on a big real world technology integration project that isn’t encumbered by the need to maintain backwards compatibility.

11) Make it feasible to seamlessly move experiment code developed by the research community into royalty generating commercial applications.

We are frequently asked what we mean by a Legacy Free design.

Does this mean we plan to totally reinvent the proverbial wheel along with every other component of a modern computer system from scratch? Of course not, quite the opposite in fact. It is our plan to scour the world for all the best ideas, throughly studying the literature of the many disciplines whose ideas merge in a computing platform.

But we can't simultaneously integrate the best technologies and maintain backwards compatibility with applications written to the API's of today's operating systems. We can't maintain today's security models and memory management policies and also fix the security problems that riddle current off-the-shelf solutions. We can't base the platform of the future on yesterday's programming languages and hope to offer the kinds of stability improvements and bug reductions that would justify the transition costs to our new architecture.

And this aspect is key, the architecture itself needs to be rethought from the ground up to realize a tightly integrated solution to the interlocking problems that make today's systems so buggy, bloated, and brittle.

The vast majority of End Users have no need for the countless Unix utilities that have agglomerated themselves together in current distributions. Backwards compatibility with DOS games written in the early 1980's has virtually no real value.

This is not to say that we oppose providing Legacy Emulation Environments, merely that they should be isolated black boxes so that the historical design tradeoffs that were needed to make them work in the era of their introduction can't spill out and impact our new design. We should also note that such LEE's can still be effectively integrated into a legacy free architecture as has been so ability demonstrated by the Virtual PC emulator's tight integration of Windows with OS X. It can be done, but this dimension of development is one that we don't plan to actively explore beyond providing the necessary hooks for others to build on.

What really matters the most to End Users is the ability to bring their old data forward, and in that regard we will provide strong data parsing facilities to make it as painless as possible for developers to import Legacy Data. For data maintained in modern formats like the countless flavors of XML, this should be a relatively trivial exercise since the old data will map to the new system in a straightforward manor. Data maintained in more obscure formats will require some non-trivial reverse engineering or a trip to one's flat bed scanner and OCR software.

As far as the feasibility of porting legacy applications to the new platform goes, it is our goal to make it dramatically easier to re-implement an older program's functionality than to port existing source code. Quite frankly most source distributions in the Unix tradition are a poorly factored mess. This is largely do to the limitations of the programming languages of choice in which they are written and the lack of standardized support for advanced functionality provided by the platforms that are targeted by the developers of such code.

Porting solutions to a new platform should be a process of elegant re-factoring, and bug & security weakness elimination. By giving developers dramatically superior tools with which to express their software ideas, we hope to make this a fun process. So while one could in principle re-implement all of the interfaces needed to port today's open source programs to the new platform, we feel that doing so would be a sub-optimal solution.

That said, as we validate various libraries and subsystems which in and of themselves are sufficiently isolated from the new platform per se, we will prototype their functionality on currently available platforms and thus see no hindrances to releasing our interim code in the hope that it will find an immediately useful life on today's systems.

The bottom line is that while a Legacy Free approach is necessary to explore the full design space afforded by modern hardware and software, Legacy Free does not mean Legacy Blind.

Our technical designs will constitute something of a meta-platform from the viewpoint of big commercial players that will provide a clean universal framework that can be safely extended in different directions without destroying application compatibility among conforming instantiations of the platform.

What this means is that platform adopters will make ontological commitments that insure that software written to the platform will be useable on any device that provides the hardware capabilities on which it depends. However, our designs will factor out alternate implementations of core capabilities from policies, behaviors, and both software and hardware-based interface affordances. This will make it possible for developers and original equipment manufacturers to radically differentiate the look-and-feel of their products without contradicting end users' mental models of what their software is doing at a conceptual level.

In this way, scrolling might be controlled by an on-screen interface widget in one implementation and a hardware eye tracker in another. Likewise, artwork might vary markedly and behaviors could be tailored to different vertical markets all within the context of a single platform from the application developer's perspective.

The first step to designing the new platform will be to begin to survey existing technologies to assess which elements need to be integrated. Fortunately, much of this work has already been completed by The Continuity Project over the last ten years of its life and its findings are the basis of our fundamental decision to make a clean break from legacy systems.

This means that we have made a conscious decision to abandon the cross-platform orthodoxy that requires new systems to be engineered with the execution of legacy code as a design requirement. Such backwards compatibility is a laudable goal that gives the end user or programmer access to old code essentially for free. But like most "free" things in life, one must pay a price. In the case of legacy support, that price is the acceptance of a large number of design tradeoffs that are grounded in historical accident and technological constraints of past generations of technology that no longer hold true.

Also, once one opts to build on a conventional platform like Unix or Windows, one has to trust in the correctness of an enormous legacy codebase (i.e. a library of software written by past programmers without the benefit of the the insights of the state-of-the-art commercial practice and academic research findings.

Thus the price of supporting legacy software is having to work within a tangle of design constraints while accepting an unknown number of bugs and security defects whose elimination would almost by definition violate one's paramount design goal of retaining the ability to run old code. Of course the degree of legacy support provided by a new system represents a continuum of design commitments ranging from full backward Bug Compatibility at one extreme to its equally radical antithesis of creating a totally legacy free Clean Room Design developed by novices who have never read the Computer Science literature and have to reinvent all of computer science from scratch.

We do not advocate such a departure from sanity, but rather mean by Legacy Free, that we won't hesitate to fully explore the design space and depart from the solutions adopted by today's dominant platforms if it makes sense to do so. As to the reuse of legacy code, our view is that we would rather concentrate our energies on making it easier to replicate the functionality of legacy systems in a safe, secure, and extensible manner than to have to go to great pains replicating the internals of antiquated systems.

Moreover, a legacy free approach is virtually the only way to re-factor today's systems to eliminate the ravages of software bloat that arise from countless libraries and applications extending the base legacy system in different directions with redundant code to accomplish the same tasks. It is also critically necessary if we are going to design our architecture to put the needs of End Users first.

For example, we would view it as preferable to create an End User graphic designer oriented layout language to replicating the cross-platform insanity of the current generations of Cascading Style Sheet specifications and then hacking them to address the Broken Box Model implementations in widely used legacy web browsers. Indeed, the World Wide Web architecture itself is fundamentally broken compared to functionality that has been fully implemented in research hypertext systems.

Also taking a legacy free stance permits us to consider mixed hardware and software designs based on input devices with multiple degrees of freedom (imagine simultaneously pointing while scrolling and zooming using a 3-D controller in lieu of taking turns fiddling with on-screen control widgets).

Our first step toward substantive development work will be to start to identify a lattice (in the mathematical sense) of Ideal Realizable Interfaces. An Ideal Realizable Interface (IRI) is a somewhat more abstract concept than the traditional Application Programmer's Interface (API) which tends to devolve into little more than an glossary of functions with inadequate documentation on their use.

API's that document libraries intended for use in a single programming language are generally expressed as so called Header Files written in those languages. Where a library is intended to be called from multiple languages its interface is often documented using an Interface Definition Language (IDL) that directly maps to a low level representation of data as used by most compilers. This makes it possible to automatically generate the concrete interface and glue code needed to call that library from virtually any language.

The problem with this model is that it works at the individual function level and fails to capture the semantics of the protocol by which the functions in the library are meant to be used. In other words, if there are rules that apply to the timing and sequencing of function calls (like a requirement that some housekeeping functions need to be called to set things up before any other routines can be invoked), they aren't captured in the IDL representation of the API. Then when a programmer misuses the API for failure to follow the informally documented rule, a bug is often manifested to the End User.

These and similar problems are generally a consequence of a premature rush to code. The Mantra that one hasn't done anything of value until it has been proven to run as working code is an ethos drummed into every budding programmer — and while it is true to some degree, make no mistake that it does have a dark side that contributes to the pervasiveness of unstable, buggy, and insecure software.

This is why we are introducing the IRI as a manifestation of our emphasis on — More Thought, Less Code.

So what is an IRI? It is a semi-formal high level analysis of the most elegant way to structure a system and invoke the services of its various components. Each IRI can be thought of as a limited Domain Specific Language.

The questions we ask developers are "What facilities would allow you to most naturally express the implementation of whatever it is your code is being written to achieve?" and "What would be the most natural way for users of your code to invoke it in other applications?" This is where the Ideal in Ideal Realizable Interface comes from. Since, there is inevitably a bootstrapping challenge in trying to describe the interface one would want to use to implement one's own work in the absence of a pre-existing catalog of such tools, we insist that the specification be Realizable. By this we mean that in specifying the interfaces on which one would like to build, one ought not require functionality that has not yet been demonstrated with a working implementation somewhere. In other words, one shouldn't predicate the implementation of some service on the solution of some open research problem. To do so, would be to define an Ideal Hypothetical Interface (IHI) instead. This can of course be done as a guide to researchers working in that area, but such alternative theoretical constructs should be regarded as optional appendices for an IRI proper.

The final element of the IRI is the interface itself and here we take a broader view than that of a conventional IDL which specifies function parameters and return values. We expand on this to include human-readable documentation, time & space complexity guarantees, Unit Tests, and representative uses. We also contemplate support for the specification of new linguistic abstractions as well as the functions found in traditional API's — an approach that should be familiar to programmers whose background includes modern functional languages like Scheme and Dylan. Finally, the IRI needs to explicitly address the impedance matching issues that arise when a library is invoked under different programming paradigms.

Our overall goal is to use the IRI as a vehicle for achieving consensus on the design of a tower of domain specific languages that will permit us to employ code switching and craft elegant and understandable systems in the large. While placing so much importance on getting these module interfaces just right may seem to be an unnecessary distraction, it is really an embodiment of Professor Arivind Joshi's dictum to Complicate Locally, Simplify Globally (CLSG) which will pay significant dividends over time.

Over the next few months we will start to list a number of specific projects for which we are seeking volunteers. In each case, we will describe the background of the project and the problem we are inviting you to work on.

If you want to tackle one of these challenges you can work on your own or you can organize a team of partners to help you with it. Unless otherwise noted, we are not yet in a position to offer any pay. But by the same token, we won't be pestering you with any deadlines either. You can tackle a project in whole or in part, as long as you are willing to donate your time & work to the public at large by releasing it through The Institute for End User Computing, Inc. under an Open Source license.

In return, we will help you find any informational resources you need and explicitly recognize your contribution by crediting you in your project's publications and on our website.