HCS has run a set of computing resources for students and student groups almost since its inception. While we used to charge for these services, we've since seen the light (or rather learned that we're not very good at collecting money) and aim to provide new and cutting edge technology directly to students. We operate on the premise that we move faster than Harvard can, so we can provide cool new things right away (FAS IT seems to take about 8 years, judging by the speed at which they adopted Apache2 - they still don't offer databases to users).

We've got a lot of cool projects going on right now, and we're always planning more. Is there something that really bothers you about technology access at Harvard? Tell us about it! Do you want to learn how to engineer real, deployed systems with thousands of users? Or do you just want to work on one of our super-cool projects (or suggest one of your own)? Join us!

This list is somewhat out-of-date. We work on it, but you'll always do better to look at the prospective projects page on our wiki.

You can reach us at systems (at) hcs ( We're very friendly.

Systems Projects


These projects are happening now and will probably never really go away.

System Maintenance
We run 5 servers (login, mail, web, MySQL, and test) plus a NetApp filer which form the core of our current production services. Additionally, we have backup mail servers, our office heads, monitoring machines, and some miscellaneous equipment currently being used to attach our office to production via a VPN. Keeping these systems running, happy and secure requires maintenance - we get a lot of traffic (something like a few web hits per second and ~28,000 unique inbound mail messages per day during the school year). Plus, we always have need for one tool or another to make maintenance easier, so we write a lot of scripts in sh, python, and perl. Right now, we're thinking about 2 larger projects: one to make Ruby on Rails easy for users (currently, they'd have to set up a proxy by hand) and one to make using external DNS names (or names of the form easy for users while running the associated virtualhosts easy for us.

Account Services/RT
We support hundreds of student groups and thousands of mailing lists. Naturally, not everyone who uses these services is an expert, so we've got to help them out. And we want to make sure that we do so in a professional manner (i.e. in a reasonable time frame, courteously, etc.), which can be difficult since we get 3-4 new requests per day. As such, we maintain and are actively improving a ticketing system (RT) to make sure we can manage our user interactions and still stay sane. RT has the advantage of being free and easier to use than Remedy, the system that FAS IT uses to do the same job. Finally, we write and maintain a series of tools to make it easy for users to get at their accounts. This includes everything from our automated mailing list generation system to simple tools for managing access lists to our grand schemes for web-based account management and/or e-mail.


These projects might be at any stage from ideas jotted down on whiteboards in our office to products that we're just about to launch. Some of them will turn into really cool things as they mature. Others will probably fizzle out for lack of interest. And of course, there are many more projects that we've thought of and which aren't even at the stage where they've made it onto this page. We encourage people to suggest projects - there's plenty of stuff to do.

We've recently written a package management system for groups so that commonly used web software (e.g. Drupal, MediaWiki, WordPress, and the like) can be installed or upgraded with a one-click interface. Hopefully, this will make our systems more user-friendly and people won't be so scared about having to use SSH. We're almost ready to launch the software and we're looking down the road at 2 questions: how do we maintain packages going forward and what software should we package?

People have been trying for years to make a single integrated Harvard calendar. The latest effort, Lonespot, while a nice website, falls victim to the same problem as all of the others that came before it: it's impossible to convince people to go read or contribute to a website unless it's already relevant to them.

We're taking a different approach. Let's assume that student groups will go to the effort of putting events on their web pages. We're writing a single piece of calendaring software which will allow web-based updates and export iCalendar feeds so that users can read the calendars they want to see in their favorite iCalendar-compliant reader (which, for most people, will be Google Calendar). Further, we'll leverage hcs-pkg so that people who install our software will have the option to register in a searchable database of calendar feeds so that new students can find the feeds they want to read easily.

HCS hosts over half of the websites of Harvard's 13 houses. Everyone agrees that houses have lots of special needs: room reservation systems, facebooks, event RSVP trackers, grille ordering systems, and the need to authenticate users against all of these systems. With the current hodgepoge of house website systems, everyone has to do all of these tasks themselves. What results is a huge disparity between the quality of websites and overall technology integration between houses.

We envision a system in which house websites are built on a standard platform with a collectively maintained core and native support for modularity. The platform must be robust enough to support the needs of a house without getting in the way, easy enough to use so that non-technical persons can edit the content, simple enough to develop for that budding developers can produce nontrivial applications, versatile enough that house websites appear heterogeneous, and extensible enough to support future needs, even unforeseen ones. In such a system, anyone who develops a tool such as a room reservation system has to use a set of interfaces which are standardized to the base platform. Then other houses can easily integrate such a tool immediately, even without strong technical knowledge.

Supporting such a system requires 2 things: declaring and maintaining a base platform, along with providing strategies to get houses to install and maintain it, and maintaining a repository for modules that extend the functionality of that platform. HCS has done several things to this effect. First, we've been actively encouraging houses and organizations to migrate their websites to Drupal, which fits many or all of the stipulated requirements for a base platform. Second, HCS is planning to run a subversion repository open to people developing tools for houses and to encourage such people to port these tools to Drupal modules. It should even be possible to leverage hcs-pkg to make house-specific modules one-click install packages. Currently, 3 houses already use (non-packaged) Drupal, and at least one is considering a switch.

Large-Scale Virtualization
Wouldn't it be cool if we could give away virtual machines to anyone who asked? We think so, too. And we're working hard on making it a reality. Specifically, we'd like to provide a system where machines could either be deployed empty and in the presence of images that could be installed and built from scratch or be deployed against one of several prototypes with pre-configured software stacks. The idea is that people with specific, common needs (say to run an application server that requires administrative access) can run preconfigured lightweight machines. People with complex needs, houses, and big projects, on the other hand, can run their own machines. Ideally, we'd support a variety of architectures and even proprietary operating systems. Interested? Come talk to us. There'll be a lot of development as this gets going. We'll hopefully be collaborating with our friends down the river at SIPB who are trying something very similar.

Single Sign-On, and PIN/Kerberos Integration
With all of these groups going to Drupal and other pieces of web-based software, we're reaching the point we've been trying to avoid all these years - the point where people have passwords for their HCS-hosted resources. Shared passwords are a huge problem, not only from a security perspective but from an ease-of-management perspective (since we have to reset them all the time). If we had some sort of single sign-on that could authenticate users via existing credentials from the UIS PIN system or from the FAS Kerberos realm or both, we could do lots of cool stuff like a web-based account control panel, web-based e-mail for groups, and the publishing of a single API for people to tie this authentication and thus an access list model into their web-based software.