Technical Oversight Committee Meeting Notes
Introductions and Organizational Changes
New members introduced themselves to the committee:
Vinoo Das from NSDC (National Skill Development Corporation) India heads engineering for a learning platform serving over 13 million learners at scale across India. NSDC extensively works with and experiments on Open edX, and has developed a software-as-a-service and platform-as-a-service version of Open edX to handle various needs from government organizations and states. Multi-tenancy was identified as a critical driver for their implementation.
Omar Al-Ithawi has been working on major projects in the Middle East and US, including EDRAAK (which reached 10 million learners) and is currently working with the National E-Learning Center in Saudi Arabia. The campaign platform focused on making Open edX work well for universities and hybrid learning, specifically targeting a migration path from Blackboard to capture approximately 30% market share within 2-3 years.
Marco Morales is based in San Diego and previously worked on the edX team in product and design roles. Currently running Schema, an ecosystem partner made up of product managers and designers (intentionally without engineering capacity), focusing on supporting and elevating product and design aspects of the R&D process.
Appreciation was expressed for Xavier and Regis for their two years of service on the technical oversight committee.
Tony Busa manages the group of engineers (9 individuals plus himself) working on the Open edX platform at WGU, partnering with Sarina Canelake and Axim’s engineering core group. Current projects include RBAC (Role-Based Access Control), rewriting the instructor dashboard, and front-end base implementation, all targeted for the Verawood release.
University Distribution Strategy
Context and Opportunity
Discussion centered on developing an Open edX distribution specifically for universities. A major national initiative was highlighted as a key use case, with universities expressing interest in migrating to open source alternatives to increase digital autonomy and lower costs.
Current Multi-Tenant MOOC Platform
Often ministry lead solutions operate a multi-tenant deployment of the Open edX platform. One case in particular focused on asynchronous MOOC-adjacent courses, serving approximately 250 tenants with a goal of reaching 500 tenants.
Key Gaps Identified
Several critical gaps were identified between current Open edX capabilities and university requirements:
Classroom Concept: Open edX does not natively recognize the concept of “classroom” or “class.” CCX (Custom Courses for edX) was characterized as a stopgap solution rather than an ideal implementation. Universities need the ability to manage sections, different class times, and shared homework/exams.
Student Information System (SIS) Integration: A major gap exists in connecting with SIS systems. While Open edX has SSO connector capabilities and can connect with most OAuth providers through Python Social App and LTI, it lacks generic SIS integration. The SAP SuccessFactors integration was mentioned but noted as rarely used. The need is for a connector base similar to the payment plugin system, allowing configuration with approximately 100 lines of code.
Live/Hybrid Learning: LiveBox was mentioned as a new feature enabling hybrid synchronous/asynchronous classes, but notification systems and other supporting infrastructure need improvement.
Instructor-Student Connection: Enhanced capabilities for instructor-to-student interactions were identified as important but lower priority than classroom and SIS integration.
Architectural Approach and Principles
Strong consensus emerged around several key principles:
Platform vs. Product Separation: The focus should be on making Open edX a platform where people can build different products, rather than making it a single product for universities. The concern was expressed that Open edX currently functions as a product delivering MOOCs, making it difficult to distinguish between product and platform.
Modularity and Extensibility: All development should follow a highly modular approach, keeping product-specific code outside the core platform. University-specific features should be implemented as plugins or extensions that don’t impact the default Open edX MOOC experience.
API Improvements: Rather than building specific integrations into the core, the emphasis should be on standardizing and improving Open edX APIs to enable easier plugin development. Course import/export functionality via API was cited as an example of the right approach.
Separation of Concerns: Teams working with specific customers should build products that meet customer needs, but these should remain distinct from core Open edX functionality. The platform should provide the foundation that makes it easy for teams to build customized products.
Multi-Tenancy Requirements
Multi-tenancy emerged as a critical requirement for large-scale implementations:
-
Scale: National platforms need to serve hundreds of universities or government departments efficiently
-
Operational Efficiency: The goal cited was running 30 universities with 10-15 engineers maximum as operational overhead (including mobile)
-
Data Privacy: Complete separation between tenants to prevent data access across organizational boundaries
-
Customization: Each tenant may require different branding (including ministerial photographs), workflows, rules, and integration points
-
Cost Efficiency: Multi-tenant architecture was contrasted with the “one instance per university” approach, which creates unsustainable operational overhead (2-3 engineers per instance)
Workflow Engine Requirements
India’s NSDC platform highlighted the need for workflow engine capabilities:
-
Integration Complexity: Government organizations require integration with their own ERPs, ministry systems, and payment systems
-
Event-Driven Architecture: Current event bus capabilities exist but need enhancement with state machine functionality
-
Tenant-Specific Rules: Different government departments and ministries have unique educational approaches and requirements
-
Scalability: Centralized workflow engines don’t work at the required scale; division by tenant enables better management
The distinction was made between message buses (for protocol handling) and event buses (which include state machines). The recommendation was to keep state machines specific to each organization, as rules and destinations will differ significantly.
Comparative Context
MIT’s Approach: MIT was noted as moving in the opposite direction – from multiple deployments to a single deployment – solving different use cases (residential, MOOCs, professional education, MicroMasters) by building on top of Open edX rather than within it, keeping Open edX as courseware while handling workflows externally.
Spanish Experience: The Spanish consortium conducted extensive user research interviewing teachers using Sakai and Moodle to understand on-campus usage patterns. They identified key integration points with student management systems and course/group creation mechanisms. Documentation from this work, including specifications for what was addressed and what gaps remained, was offered for sharing with the committee.
Migration Path and Standards
The discussion touched on making migration from existing LMS platforms (particularly Blackboard, Canvas, and Moodle) more straightforward:
-
Conceptual Mapping: While differences exist (e.g., Canvas sections vs. Open edX course runs), there’s more overlap than typically acknowledged, requiring translation layers and plugins rather than fundamental rebuilding
-
Feature Parity: Some gap analyses may overstate differences when considering that basic mechanics of campus LMS platforms have significant commonalities
-
Previous Initiatives: Multiple past efforts (including ASU, OpenCraft, and Spanish consortium work) have explored campus adoption, though budget constraints often prevented full implementation
LTI and Standards
LTI (Learning Tools Interoperability) was identified as an area needing continued improvement despite recent certification achievements. Making LTI more user-friendly, operator-friendly, and student-friendly was highlighted as valuable for everyone, not just university deployments.
Market Opportunity
The potential market was estimated at approximately 30 countries that would be interested in national-scale university LMS platforms. This excludes countries that have already implemented their own solutions or those that can use simpler solutions like Moodle or Google Classroom. The estimate suggested at least 30 universities per country could be served.
A 5X multiplier in active users was projected if universities adopt Open edX broadly, compared to current Open edX usage levels.
Next Steps Identified
Several action items emerged from the discussion:
-
Nacho to share the Spanish consortium’s specification document (translated into English) with the TOC list
-
Regis to search for data from the 2024 presentation that included valuable inputs
-
Consideration of reactivating the campus working group to enable coordination among interested parties
-
Development of a collaborative roadmap incorporating needs from Saudi Arabia, NSDC India, eSHE, Spanish consortium, and potentially ASU and Ethiopian universities
-
Prioritization exercise to sequence technology development, potentially starting with minimal feature set to “land the fish” before expanding
-
Assessment of whether features like SIS integration, payment operations, and other systems have broader applicability beyond university-specific use cases
Summary of Architectural Consensus
The committee reached consensus that:
-
A university-facing package built on top of Open edX Core would be valuable in the market
-
Product-adjacent code specific to university use cases should remain outside the core
-
The package should be shareable among universities but function as a product built on the platform
-
Investment should focus on making the core more solid and smaller, enabling multiple types of products to be built on top
-
Recent architectural work (clarifying the core, making it smaller, enabling extensions) positions Open edX better for this approach than in the past
Digital Credentials Strategy
Current Situation
2U announced they are moving away from their role maintaining the credentials service, prompting a timely conversation about the future direction for credentials in Open edX. The current credentials service offers some valuable functionality:
-
Adapts Open edX attainments into the Open Badges 3 standard
-
Can send credentials to Credly and Accredible
-
Only works for a subset of attainments on the platform today
Investment vs. Deprecation Decision
The committee discussed whether to invest in improving the credentials service or deprecate it entirely. Key limitations of the current implementation were noted:
-
Would require investment to make it work for all attainments (not just the current subset)
-
Would need to become the default if investing further
-
Should likely retire existing credentials code in the platform core if investing in the separate service
-
Contains significant technical debt
Broader Ecosystem Opportunity
Discussion explored the potential value of an open source Learner Record Store (LRS):
Market Gap: No strong open source contender currently exists for a comprehensive LRS, despite several started-but-not-sustained projects. This was characterized as a significant miss for the EdTech ecosystem.
Analogies to Financial Systems: Credentials were compared to currency that learners can spend to get jobs (with the unique property that using the credential doesn’t deplete it). Just as banking has standards for digital transactions, credentials have standards for digital representation and verification (like Open Badges 3), but lack widely adopted implementation platforms.
Network Effects: The credential space was identified as potentially one of the few areas where Open edX instances could connect as a network or catalog network, creating value across the ecosystem. Unlike course creation, grading, or enrollment (where alignment is difficult), credentials offer opportunity for standardization and transferability.
Mobile Integration: A shared credential wallet was mentioned as a candidate feature that could drive higher Open edX mobile adoption rates, enabling learners to carry portable credentials across institutions.
Standards Landscape
Multiple standards were discussed, with complexity around choosing the right approach:
Open Badges 3: Characterized as decent compared to other EdTech standards and substantially less complex than LTI. The standard enables digitally verifiable credentials owned by earners that are transportable and survive potential decline of issuing organizations.
CLR (Comprehensive Learner Record): The 1EdTech CLR standard was referenced as defining a broader scope including in-person activities, webinars, and off-platform learning—more comprehensive than current implementations.
Regional Variations: European standards (ELM) and other regional approaches exist, creating a “Tower of Babel” situation where lack of common language hampers the ecosystem.
Standards Skepticism: Concern was raised that when standards don’t achieve adoption, it may indicate the standard itself is problematic (potentially “bloated” or overly complex), suggesting need for simpler alternatives.
Pragmatic Interoperability: Rather than committing to one standard for storage, the suggestion was made to store credentials in a flexible format that can be easily exported to multiple standards (Open Badges 3, CLR, etc.), similar to how the platform now supports multiple taxonomies.
Alternative Approaches
Several alternatives to maintaining the credentials service were considered:
Open Wallet Foundation: The foundation’s work on digital wallets was mentioned as potentially providing the answer, possibly allowing Open edX to deprecate its credential service in favor of recommending external wallet solutions.
Plugin Architecture: One option discussed was moving adapters (Open Badges 3, Accredible, Credly) into optional plugins running in the platform runtime, catching events and pushing credentials to external wallets.
Existing External Services: Currently, most implementations rely on closed, paid provider networks (Parchment, Degreed, Credly, Acclaim) rather than open solutions.
European Integration: Spanish universities (particularly Carlos III University) are leading integration with European digital credential systems. Valencia hasn’t implemented yet but can facilitate connections to universities with active implementations. The German University of Digital Science was also noted as very interested in credentialing.
Technical Architecture Considerations
LRS vs. Data Lake: Clarification was made that an LRS differs from Aspects (which functions as a data lake capturing every learner action). An LRS would store refined data: courses completed, grades, competencies mastered, with timestamps.
Event-Driven: The current architecture uses events fired when learners complete courses, consumed by the credentials service to trigger credential issuance. This pattern could be maintained with plugin-based implementations.
Storage Format: Emphasis on ensuring stored credentials include high-level concepts shared across standards (linked evidence, verification mechanisms) to enable easy export to multiple formats.
User Experience Considerations
Certificate Diversity: Recognition that educational systems have multiple credential representations (badges, certificates, transcripts, records) that need accommodation.
Gamification Connection: Badges and gamification were noted as closely tied to the credentials concern.
Baseline Functionality: The importance of out-of-the-box utility was stressed—avoiding situations where every Open edX adopter must reinvest in building basic credential functionality, which chips away at the platform’s value proposition.
Standardization Value: Even if a credential display service isn’t provided, ensuring credentials are issued in universally acceptable formats that can be pulled into external credential services was identified as minimum valuable service.
Current Implementation Gaps
The credentials service was characterized as never fully implemented:
-
Program credentials were built one way while course certificates remained on old systems
-
Development occurred during a slow period of edX re-architecture
-
The vision of a unified credential system across all attainment types was never realized
-
Multiple parallel systems created maintenance burden and user confusion
Committee Perspectives
Deprecation Support: Strong support was expressed for deprecating the current service if it no longer serves the community well, especially given 2U’s withdrawal of maintenance.
Replacement Plan Needed: Concern that simply deprecating without a plan would lead to fragmentation, with every instance implementing credentials differently, further reducing Open edX’s competitive position against platforms with better out-of-box credential support.
Investment Consideration: Recognition that if investing in credentials, architectural review is needed to determine the right foundation—possibly building on recent proposals rather than the current implementation.
Ecosystem Impact: View that credential functionality is so central to the learning experience that lacking it puts Open edX at a disadvantage, representing another checkbox that can’t be checked compared to competitor platforms.
Next Steps Identified
-
Review of the credential proposal document shared by Xavier
-
Asynchronous continuation of the discussion
-
Decision needed on whether to deprecate without replacement, deprecate with recommended alternatives, or invest in improved implementation
-
If deprecating, ensure clear migration path and recommendations for adopters
-
Consider whether Open edX should build and maintain credential infrastructure or integrate with external solutions