I’m an unapologetic fan of professional gatherings. I like them less for the formal presentations than I do for the informal conversations that follow. Case in point: it was one of those conversations at the dLRN conference in October that led to last weekend’s Indie Ed-Tech Data Jam at Davidson College. You can read more about that in Adam Croom’s first reflection on a weekend that turned out to be one of the most intense, rewarding, and promising gatherings I’ve been part of in a long time.
Too often the momentum for the ideas that emerge in these conversations fades once you return to the urgent work on campus. This one did not. In my mind that has everything to do with the collective work around Domain of One’s Own (DoOO) and the Personal API.Jim Groom, Tim Owens, and Kin Lane are challenging us to look at our systems of ed-tech in another way. And we’re all in because this is the kind of ed-tech that goes directly to what we value most: student-centered, student-owned learning. There are great examples of this in DoOO schools –OU Create, VCU’s RamPages, etc. I will briefly describe the impact we’ve seen at Davidson:
When we first rolled out DoOO at Davidson, we pitched it as the ‘anti-Moodle’. For us it represented a breaking down of hierarchies. DoOO moved control of digital spaces from the institutional LMS to the individual teacher and student. In the classroom, domains have broken down those hierarchies even further. As Andrew Rikard wrote so eloquently last summer, this is significant not because of the technological shift, but because it supports a pedagogical shift.
DoOO is critical pedagogy. It is a technological reminder that scholarship happens in conversation. Students own their ideas in the form of content. Where that content resides becomes part of a negotiation. When students are empowered by the tech that lets them drive this part of the process, ideally they see how to drive their own ideas within the scholarly process.
So, that’s good ed-tech, but why is it ‘indie ed-tech’?
Adam opened the weekend by asking us to lay out our own definitions of indie ed-tech. Here is my reflection, cemented by Audrey Watters in her fantastic opening talk. Her first two lines go to the heart of my thinking:
The title of this talk could as easily be “indie versus institution” as “indie versus industry.” I have no love lost for either.
Indie is first and foremost about the individual. It’s DIY. It stands in opposition to corporate controls, but it doesn’t seek to destroy the system itself. That’s the way it works in indie art, music, film, etc. It’s an intellectual resistance, with a goal to improve it. We talk about indie ed-tech mainly in opposition to corporate ed-tech. But indie is really about resistance to any structures that seek to manage or control the individual.
This is what DoOO fosters and where indie ed-tech in general holds the most promise in my mind. As it pushes back on Silicon Valley and corporate priorities (i.e., procurement, digital courseware, the LMS, etc.), it simultaneously pushes back on our own institutional structures that, intentionally or not, prop up those corporate priorities.
While we are right to push back on Silicon Valley to clean up their backyard, perhaps we should clean up our own backyard first. For me that means creating what Tim Klapdor calls a new ‘infrastructure that supports scholarly agency and autonomy.’ DoOO is one layer. The University of the API is another…
API’s: “They will come and help you build it.”
Prior to the event, Kin Lane led a meeting with Davidson’s IT Leadership team to talk about campus API strategies and their potential to support the core mission of higher education – teaching and learning. No one has embraced API strategy as completely as the team at BYU – Kelly Flanagan, Phil Windley, and Troy Martin -who joined us for that meeting. These guys are my heroes.
The next stage in BYU’s API strategy is to develop the ‘personal API’, and a use case we could run at multiple schools was the ultimate design goal for our weekend at Davidson. Perhaps the best piece written about the BYU effort is this one by Marguerite McNeal. If you haven’t read it yet, make a point to do so. The personal API is not easy to grasp. This piece clearly explains both the concept and the potential.
Talking about the potential for API’s, Kelly delivered perhaps my favorite quote of the weekend: API strategy, he said, is reversing the equation from ‘if you build it they will come’ to ‘they will come and help you build it.’ Kin and the folks at BYU are laying the foundations for a new value proposition in higher ed IT. In a time when we expect modern learners to move from consumers to creators, the infrastructure that supports them also has to empower them.
I can’t think of a better way to close than to share Kin’s reflections and summary of how ‘API’s will deliver the change we need.’
Many thanks to everyone who came to the Davidson meetup and to all who continue to work on this effort going forward. Special thanks to Adam Croom and Eddie Maloney for co-hosting the first conversation. And Alan Levine for the awesome first reflection and photos.
Thanks to expert guidance from Known’s Ben Werdmuller and Erin Richey, who ran a perfect design sprint, we have good prototypes for the personal API. Future work will be openly shared on GitHub. Tom Woodward is already off to the races. And the students are leading a prototype build this summer. Talk is cheap. We have to start building for change.