Home Page

Welcome to the Learning Management Operating System (LMOS) homepage.

WE ARE MIGRATING OUR SITE TO: http://confluence.sln.suny.edu/display/LMOS/Home

Contents

Release Goals
Available Portlets
Potential Portlet-able Applications

Use Cases

Repository update sends announcement and creates discussion?

Vision Statement

As we look out at the current state of Learning Management Systems (LMS's), we see a number of unmet needs for every level of stakeholder, from individual student up to institutional consortium. Principal among these needs are as follows:

• For students, more control over their own data: The current generation of LMS's tend to be course-centric rather than student-centric. Student-created content, such as assignments, is submitted to course silos and is only re-exported to student-controlled portfolios as an afterthought--often with some difficulty. Likewise, personal content that should be aggregated, such as assignment due dates, campus club meetings, and other calendar events are segregated in their own silos rather than being available to the students in a unified view. The next generation of LMS's should put students, not classes and groups, at the center of the design.
• For faculty, more control over the learning environment: The current generation of LMS's tend to be designed with a core set of applications that are the only available as a group and then a relatively limited set of (often proprietary, and almost certainly non-standard) integration points for add-on applications. Faculty are stuck with a core collection of applications, with their only option often being to turn an application off if they don't like it, and have limited ability to add specialized applications or configurations based on the disciplinary content, the level of the student, the teaching style of the instructor, or other factors that tend to make each class a fundamentally idiosyncratic experience. The next generation of LMS's should be optimized to give faculty the maximum ability to construct a virtual classroom that is tailored to the needs of their particular students, content, and methods.
• For institutions, more integration with their other campus IT systems: Today's LMS's generally require specialized conduits and integration efforts for each type of IT system with which they may need to integrate, e.g., Student Information Systems (SIS's), library systems, campus portals, etc. This means that, as campus IT systems continue to become richer, more complex, and more interdependent, institutions are faced with the stark choice of either investing an increasingly large percentage of their resources into a never-ending series of discrete integration projects or accept that their LMS will slowly become an island unto itself. The next generation of LMS's should interoperate deeply with existing integration frameworks within campus IT, such as the campus portal and LDAP.
• For consortia, more ability to share computing resources without sacrificing needs of individual members: Many of today's LMS's are primarily designed to serve the needs of one individual institution and are ill-suited to resource sharing among multiple institutions. Configuration settings, ranging from administrative roles to branding, are often global system settings. In addition, current LMS architectures tend to be optimized for centralized hosting and are not well designed for pooling of distributed computing resources across multiple institutions. The next generation of LMS's should provide options for consortia of smaller institutions to intelligently pool resources without having to accept a "one-size-fits-all" configuration.

It would be unfair to declare that no existing LMS meets any of the goals outlined above. In fact, most of the mainstream systems on the market today attempt to satisfy them on one level or another. However, we believe that it is fair to say that the functionality designed to meet the goals have been bolted on as afterthoughts in most current-generation systems, in large part because the importance of the goals themselves has only become apparent recently as campus needs and IT environments have evolved and as online teachers and learners have grown more sophisticated. We think that the time is ripe to refactor LMS architecture in order to put these four goals front-and-center in the design. We envision a system which is built from the ground up to support inter-institutional computer resource sharing, interoperate seamlessly with campus IT integration systems, provide unprecedented faculty control over virtual class experiences, and present a consistently user-centric view of all data. We call this new architecture a Learning Management Operating System (LMOS) because its primary intent is to provide a framework of interoperability upon which customized and integrated learning environments can easily be created rather than providing a monolithic learning environment in and of itself.

Mission Statement

We believe that the strongest test of an interoperability and integration framework is actual interoperability and integration with existing components. Therefore, the LMOS project will seek to achieve appropriate levels of interoperability with a broad cross-section of Open Source projects (and proprietary products) as quickly as possible. We conceive of our project as being closer in its organizational nature to a linux distro than to an application development project: i.e., it is fundamentally about assembling a collection of existing components into a coherent whole. We will seek to aggressively partner with as many existing projects as possible and will own as little code as possible within the LMOS project itself, preferring to cultivate cross-pollination among the various existing development communities within our ecosystem.

Our current approach is to use the portal as the architectural centerpiece of our project, since today's portals are designed to meet the goals articulated in our Vision Statement, and since we see increasingly broad penetration into university IT departments. This would involve assembling appropriate JSR-168-or WSRP-compliant components from various projects, including but not limited to elements from the JA-SIG Clearinghouse and Sakai, and providing a composite reference distribution that demonstrates the viability of the LMOS concept using primarily pre-existing parts. However, the choice of these technology standards and components is purely pragmatic; both can be adjusted based on input from participating communities. The main point is to choose a starting place for the project where a substantial percentage of LMS components already exist within compatible technology frameworks.

At the same time, we do anticipate that further development will be necessary in order to turn a proof-of-concept into a production-ready system. In fact, a principal goal of the LMOS project is to identify current gaps in both functionality and interoperability that would need to be filled in order to achieve production quality. One of the first and foremost development challenges will be to create a flexible service broker that will allow components and integration points to be added dynamically to the system and recognized by existing components as new needs are identified. We seek to collaborate across various component projects to create such a framework and, if possible, find a home for this functionality within an existing Open Source community. We also seek to identify existing components (both Open and proprietary) that may not yet be fully compliant with our integration framework (JSR-168, WSRP, etc.), but whose functionality, architectures and supporting communities (or companies) are compatible with the aims of the LMOS project. The creation of new and independent application development efforts will be considered in order to achieve our vision, but only as a last resort.

The technological mission, as articulated above, is intended to be guided at a fairly granular level by the four stakeholder communities identified in the respective goals articulated in the vision statement. Development priorities will be set according to their ability to meet the stated needs of students, faculty, institutions, and consortia. We intend to recruit stakeholder representatives at all four levels to provide ongoing guidance regarding design and development. We view failure to do so as one of the most significant potential risks to the long-term success of the project.