Educoder is an idea that began 8 or 10 years ago, and we managed to actually get funded: a ‘professional community’ for technology developers in the learning sciences. As part of our earlier NSF TELS center (2003-2008) we had a dozen or so techies, and organized annual “techie retreats” where we got all the programmers together and talked over various issues, played card and computer games… building community…
In 2006, Jim Slotta got involved in a large E.U. collaboration, where there were another dozen or so techies, concerned with many of the same issues, platform decisions, etc – and a spectrum of collaborations. He managed to get some funding to bring 20 or so of these techies to get together in 2008, and we formed this group called “educoder” – including a drupal portal that we built with that funding – see educoder.org Later in 2008, Slotta wrote a small grant for 50k (over 12 months) to support educoder, called CCSIP (Canada California Strategic Innovations partnership). Titled “the role of a technology community in a scientific discipline,” it funded two retreats (one in Toronto and another in California) that included 20 or so techies from across North America and Europe. See the grant proposal – which describes the idea and agenda in full detail.
In 2010, we wrote (and won) a follow-up proposal to CCSIP, to create a “sustainability plan” that would build a cost effectiveness argument for educoder. That proposal (linked here argued that there were three areas where educoder could be an important – and cost effective – factor within the learning sciences: 1. Platform decisions: e.g., If TELS/WISE had had better discourse amongst techies when we chose Java for WISE 3, we might have saved $3 million of NSF money (amount spent on the now-dead WISE Java client, roughly). 2. Design processes: some new methods are emerging, beyond Xtreme programming, including paper prototyping, wizard of oz, etc – and there should be discourse about these. 3. collaborations: We often ask techies from our respective labs to collaborate as part of new funded projects, but they don’t know anything about each other’s lab… no idea about the tools and practices, etc. Then all of a sudden… they have to make their stuff work with the other lab’s stuff (see the need for more opverarching community?) All of these things seem to argue toward a cost effectiveness argument, which will be presented to the ISLS business meeting in Sydney, 2012.
A persistent technology community seems to offer a straightforward “Human Resources argument” that would allow our field to better support the growth of knowledge, sharing of best practices about platforms and design amongst our (traditionally silo-ed) tech developers and designers, and enable collaborations and scaling. We just need to prove it to the learning sciences community, so that investigators would, for example, write “travel for techies” into their next round of grants – allowing this community to move forward indefinitely. (note: it is likely to move forward indefinitely no matter what – these guys are already a community…)