Introduction

About Chris

Meet BRIC co-founder, Chris J. Karr.

Chris J. Karr

— 5 min read

My first experience writing and supporting research software began in the summer and fall of 2000, during my junior year of undergraduate computer science studies at Princeton University. As a sophomore interested in tech and policy, I took a course offered by Tim Feddersen – then, a visiting professor from Northwestern University – called Online Democracy. Prof. Feddersen worked with Princeton’s local Office of Information Technology to put together a motley collection of tools to facilitate the class's online experience. We had virtual deliberations through web-based chat, explored electronic voting, and dived into what happened when traditional governance practices met the online world.

My final paper for the class was a review and critique of the systems he’d assembled. It was apparently good enough that he approached me after the class was finished with a fellow professor and business partner - Daniel Diermeier - from his academic home at Kellogg School of Management to build a system that implemented the suggestions I mentioned. I was scheduled to spend the summer of 2000 in Russia in a language immersion program as part of my undergraduate requirement that I demonstrate proficiency in a foreign language. I spent more time banging out PHP code than studying Russian in my small room overlooking the Griboyedov Canal in the heart of St. Petersburg. I failed my language immersion program, but I had completed an early version of a suite of tools for online decision making. Outside of class, I spent my fall semester wrapping up that work before Prof. Feddersen was going to teach the next iteration of his class back at Northwestern during their winter quarter.

I finished the suite in time (along the way, it morphed from a research project to a short-lived Dot-Com start-up called ElectionWare), and I ran my first research study with these new tools from my coffin-sized dorm room in Princeton’s Brown Hall. I learned quickly that just because a system is deployed doesn’t mean that it’s finished. The real world has no shortage of curveballs it is eager to throw at software developers, and I spent a good amount of early 2001 patching and refining the ElectionWare system while the class was ongoing.

As graduation approached, I had a brief flirtation with pursuing a career in the traditional tech sector. I was pretty far through the hiring process with a young company called Amazon, but ultimately decided that I was more interested in working to tackle novel problems that pushed the boundaries of human knowledge than I was in getting rich as a consultant or part of a start-up selling stuff to consumers online.

By the time I graduated (the Dot-Com Boom had become the Dot Com Crash), ElectionWare had reverted back into a research suite, and a team at Northwestern was continuing the work I had started. I asked Tim who was doing that work, and he referred me to a unit within the university's central IT department dedicated to supporting faculty in their research and teaching endeavors. I interviewed with that group, presented the work I was doing with passive sensing as part of my Senior Thesis project, and they hired me. So, my first official job out of college was working with educators and researchers to push technology boundaries, and that’s largely been my profession ever since.

In future posts, more of my history creating, disseminating, and supporting research computing systems will come out, but I wanted to lead with the ElectionWare story to demonstrate that I’ve been thinking about the intersection of research and information technology for most of my life. Today, I’m currently the “Founder & Chief Developer” of Audacious Software, a consulting company I bootstrapped after leaving graduate school in 2009, where I’ve worked with researchers and institutions around the world tackling a variety of novel problems:

In my role as the sole proprietor of Audacious Software, I’m always on the lookout for opportunities that don’t just solve one problem for one client, but solve a class of problems for a variety of clients. (A look at the company’s public open-source GitHub repositories and my Google Scholar profile will provide a clue of how many problems I’ve tackled for clients.)

With the growing demand I’m receiving as researchers publish the work that my systems enabled, and others come out of the woodwork seeking to do something similar, the sole-proprietorship structure of Audacious Software is proving less sustainable and scalable as demand has ramped up. Word-of-mouth has been strong enough that I’ve never had to spend a penny on marketing, but staffing has proven to be a continual challenge, as the kinds of developers I need for this kind of work (creative developers with a strong internal initiative) are already gainfully employed or creating products and companies of their own. Furthermore, in an environment where research is primarily publicly funded, and those receiving the funding are non-profit institutions themselves, a small company like mine will eternally be relegated to support and contracting roles. To grow further in any meaningful sense would mean abandoning my existing academic research client base, and seeking more lucrative work in the private sector.

Rather than pivot the existing company to a different client-base, I'd like to continue working to empower scientific research, so I approached my BRIC co-founders with the idea to take the technology that I’ve built with Audacious Software, and using that as a foundation for a new independent organization - designed from the beginning - to support research on a project-by-project or platform-by-platform basis, but also to advise, educate, and prepare others for working in research technology fields, just as I’ve had the privilege of doing for the past quarter century. There’s a lot that I’ve learned during that time, including identifying some concrete opportunities for raising the tide for scientific research.

From my perspective, BRIC will be a success if it can serve as a force for positive change in research settings. That includes more effective leveraging of open source components to solve common problems (and no longer reinventing the wheels), promoting sustainable software development techniques and practices in teams creating research systems (not just our own), supporting the global scientific effort by providing necessary and under-provisioned infrastructure and services that enable initial investigations and promote replication. The ultimate goal is to spend less time revisiting the same problems over and over, and spending more time "on the shoulders of giants" pioneering new technologies and methods that enable scientists to push the boundaries of human understanding further and faster.

Working as a research software developer can be less glamorous and financially rewarding than the alternate path that I might have taken two decades ago. However, there is a unique joy in knowing that my efforts every day are a key contribution towards answering questions that matter, and leave the world richer in knowledge than I found it. Make no mistake, there are plenty of headaches and frustrations in this line of work – having to deal with older legacy systems, additional education and certification for dealing with human research subjects, staying performant and secure in a constantly shifting technological landscape, etc. – but one problem that I never have any problems with is heading to the office unsure of whether what I’m doing that day will have a positive impact on others.

BRIC is my attempt to bottle up that sentiment and attitude and package it in a form that that I can share with others who may be similarly inclined.

Read more