Innovation | Feature

Duke Co-Lab Invites Students to Write Their Own Technology

• By Dian Schaffhauser
• 10/02/13

Co-Lab Hackathon (Photo: Michael Faber, Duke University)

As a freshman at Duke University Robert Ansel was frustrated that he couldn't use the e-print service available on campus through his smartphone. This double major in Electrical & Computer Engineering and Computer Science determined to build an app to do so, and then he promptly put it on the backburner -- until, that is, the following school year when he heard about a couple of freshman who had actually developed the beginnings of a mobile app to do the very same thing. Although they had figured out how to send files from a phone to a "server somewhere," they couldn't figure out how to build that server component, which could convert the files and print them. They put out a call for help, and Ansel and his friend Jason Oettinger answered.

But the deal was sweetened by the prospect of finishing something in time to enter it into a new development challenge put up by Duke's new Innovation Co-Lab. The deadline for submissions was just days away.

"I said, 'Hey, if we can get it done in time, we should enter it. It seemed perfect," recalls Ansel.

The final result, DevilPrint -- named after Duke's mascot, the Blue Devils -- ended up taking first place in that competition, winning the team a $3,000 prize. Now the four students are pursuing the creation of a start-up to continue development work on the app.

That's a prime example of what the Co-Lab environment was set up to do in the first place, says IT Innovation Manager Michael Faber: "to empower students to take more ownership of the technology environment that has traditionally been handed to them."

While some might view the Co-Lab as a case of the inmates being left in charge of the asylum, it's actually an experiment to see what students can come up with, given deadlines, incentives, community support, and resources to help them accomplish their goals.

"We don't know what kinds of things people are going to come up with," Faber acknowledges. "We don't know where they're going to take the ideas." But Duke's ready and willing to find out.

Along the way, the Co-Lab is also providing that all-important link between a college education and hands-on experience that college graduates are being asked to prove more and more in the workforce and that typically are acquired not from the classroom but from informal learning experiences.

Incubation of an Incubator

In the past, explains Faber, the job of Duke's Office of Information Technology or OIT was to "create technology and then to hand it out to students, faculty, and staff to use." But as technology has become "more accessible and able to be democratized," students have been put into a position where they should be able to take a role in actually shaping and directing it. "The students probably know best the kinds of needs they have that technology can solve. So why not give them the opportunity to solve it with the backing of the centralized IT organization?"

The Co-Lab's role is to create the environment in which that can happen. That means providing both technical and human expertise. It might involve hooking up students with the right people inside OIT to review code, explain how certain campus applications work, and help with security issues. It might call for providing a virtual server upon which to deliver the app.

That's exactly what happened with DevilPrint. When it was first submitted, says Faber, "It was not the prettiest code." The program ran on a laptop in one of the students' dorm rooms and was accessible by a total of six people. The Co-Lab was able to connect the team with the actual service owners of the e-print program. The person in charge of that looked over the code and gave them suggestions for improving it. Then it worked with the students to address security aspects of the app.

Also, the Co-Lab moved the app off a laptop and onto actual OIT servers. That was an invaluable service because it felt like a real-world experience, Ansel emphasizes. OIT "set up these virtual servers within Duke's firewall allowing students to connect to these computers and build whatever they want from the ground up. We put DevilPrint on a Co-Lab server and did all of our development remotely. Out in the business world, that's what people are going to be using. You don't usually do your programming on your own computer. You're programming and pushing your changes to a remote machine out there in the cloud somewhere. That was really helpful, having that option to connect to our own machine."

Of course, Ansel adds, "They give you enough rope to hang yourself." In the case of DevilPrint, the development team forgot its password for accessing the virtual server. Co-Lab came to the rescue. It also did a migration that managed to break not only the app code but also the instance of Ubuntu that was running on its virtual machine. "That's where we learned our lesson that backups were very important," he observes. Fortunately, the team had a backup of its own code, and Co-Lab had a backup of the scripted files used in running the app.

Not Just for Techies

Events take multiple forms: open ended challenges, such as the one the DevilPrint team entered; shorter duration competitions such as an upcoming "Big Byte Challenge"; and "Studio Nights," open weekly meetings that run like user groups.

Although the Co-Lab is currently tilted a little bit towards computer science and engineering, it has designs "to branch out and get more people involved," says Faber.

For example, a quick read of the Big Byte Challenge suggests that it's a hackathon, "where students will be given a weekend to learn APIs and show us what they can create with real-world company data." AT&T and Apple are sponsoring it, supplying that "company data," doing student recruiting, and handing out prizes like MacBook Airs and iPads.

But in the fine print the Co-Lab invites participation from students both technical and non-technical. What's a non-technical person going to be doing over the course of the four day event -- handing out the pizza?

Faber suggests a couple of outcomes. First, there's the magic that can happen when left-brained people interact with right-brained. (Think Jobs and Wozniak.) "Duke is full of creative, interesting people who have lots of ideas about things that could be better or beautiful or interesting. Getting those people in the same room as somebody who can actually execute that stuff is the first step."

The second outcome is related directly to the use of big data sets, the theme of the event. Yes, while some participants will be writing code to access the data or do some activity using the data, others could be working on projects that display the information "in a really interesting way."

"Getting those kinds of creative minds together -- the visual people along with the technical people who can access the data and write the code that underlines a beautiful visualization -- is really valuable," Faber says. "Building up that community together is part of the Co-Lab mission."

Another non-techie event will be an upcoming "iconathon," a five-hour Saturday workshop to develop a set of graphic symbols "that can be used to easily communicate concepts frequently needed in civic design." Suggested by Faber and sponsored by The Noun Project, a non-profit organization building a global visual language, this activity will focus on innovation in education, especially massive open online courses (MOOCs), which Duke is a heavy participant in. After hearing experts explain the basic concepts, participants will set to work creating symbols that can be used as a visual language in these globally available classes.

The Sustainability Question

The benefits of the Co-Lab don't all flow towards the students. According to Evan Levine, assistant director for OIT Academic Services, which oversees the Co-Lab, while OIT is providing resources for the students, the challenges and other Co-Lab activities are also delivering a shot of fresh air for the IT staff. "Oftentimes, we get bogged down in the bureaucracy of a large organization and won't go out and experiment and try things. Working with the students is refreshing in that perspective as well."

Of course, if Duke OIT adopts a student-developed service created through the Co-Lab, those same staff members could face the unenviable task of supporting that service once the student has graduated and moved on in life.

Levine identifies that prospect as "one of the bigger challenges we're going to face." One possible outcome is that OIT acknowledges that the app or application or service is "meeting an enterprise need on our behalf" and takes over management and updates for it. Another potential outcome is that other students would pick up the service "and keep it going as a community effort of some sort."

In either event, adds Faber, part of the value of getting OIT experts to review the code being submitted is to ensure the students "make it as sustainable as possible."

Because the Co-Lab hasn't had to deal with that yet, it doesn't know what will happen. "Once we do, we'll use that as a test case and see how we can build a process around it," Faber notes.

Or it could be, Levine notes, that the student teams take the technology with them when they leave. The Co-Lab is addressing that prospect as well by setting up a framework for providing the kind of help any start-up initiative would need. Under the umbrella of Duke's Innovation and Entrepreneurship program, students could receive support in areas such as legal structure and even office space. In fact, the crew behind DevilPrint may be testing that kind of help out next, since it intends to continue developing its app beyond the confines of Duke's use.

Levin expects the next competition, the DukeMobile Challenge, which ends in early October, to be a real test of the interaction between what the students are doing and what the Co-Lab hopes to grow on campus. The university has updated its campus mobile app, DukeMobile, and students are being invited to build modules that could be included in the new app when it's rolled out. To encourage that, OIT has developed Streamer, a middleware technology that lets students access campus data such as class schedules and maps to use in their own apps.

For instance, Ansel, part of the winning team that produced DevilPrint, plans to enter a module he's personally building that extends Duke's existing data about campus dining to include other features, such as location awareness to help users find the closest food and options to list food trucks and off-campus businesses that deliver food on campus.

But the introduction of student-made apps could be tricky, says Levine. "We're going to have to have slightly more rigid policies in place. Once we have something branded as 'mobile.duke.edu,' the way in which an app or an icon would make its way in there has to be somewhat official." That includes meeting specific needs (not just for students but for any users on campus, including staff and visitors) and following branding rules.

Even if an app doesn't pass muster for being included in the official campus version, the Co-Lab is building a marketplace where students can distribute their apps in an enclosed environment. "If they prove us wrong and show us that it's a worthwhile thing, then of course we can revisit it," says Faber.

But always, he adds, the Co-Lab doesn't want to be too proscriptive. "Our challenges are meant to be very open ended and allow for creative solutions to come out so we aren't pushing an agenda. It's more about getting [students] to be working on something interesting and then seeing what comes out of it."

Giving Students Practical Experience

Granted, because Duke is a Tier One Research University that long ago earned its reputation as an incubator of innovation, it may have a built-in affinity for setting up a structure such as the Co-Lab to help immerse students in the creation of their own technology solutions. But that doesn't mean other institutions can't take what Duke is doing and apply the format in their own environments.

Faber recommends that those considering a similar initiative view it as a grand experiment, like a start-up: "something that has to change quickly, move nimbly, pivot if necessary." Every chance he has, he asks students whether a particular activity was valuable and whether it should be repeated, or adapted, or modified -- "Co-Lab jujitsu," as he calls it. "I don't really know what the spring semester Co-Lab is going to look like, because I want to see what we're doing now and what works." In other words, a student innovation incubator needs to cater to the students participating.

Ansel advises schools to make sure they have somebody dedicated to staying in direct contact with students on a regular basis. By having Faber in that position, he says, "whenever students have questions about anything involving OIT architecture, they have a go-to person they can contact." During the development of DevilPrint, as questions would arise, the student team would contact Faber, who would find the right person for them to speak with.

But on top of that, he adds, it's important for that student liaison "to be listened to as if they are speaking for the entire student body. They're going to be knowledgeable about what students want and what they think would be really cool to have. If they're not given any leeway in telling the university that students want a particular product and the university doesn't listen to them, there isn't much of a point in having them."

Levine encourages getting executive-level backing from the right people on campus to make the program work. "We're lucky that our executive sponsorship for this program is the president, the provost, the executive vice president, and the Innovation and Entrepreneurship program at Duke," he says -- especially considering that nobody knows what the outcome is going to be. "Being able to explain the benefits of that and getting buy-in from the right people is key to making this work."

Of course, the outcome isn't necessarily a total mystery: Students are getting practice in tackling "real world, nitty-gritty projects." Co-Lab is providing the "experiential education counterpart" to traditional classroom learning, says Levine, "They're going to run into problems that they're not going to see in a textbook: 'How do I organize a team properly?' 'Who are the good people for my team? 'How do I keep my code straight from my teammates' code?' 'How do I deploy to a server?' It's important for us to give them opportunities to have those types of experiences while here at Duke."