How to build a Github in a university?

This post is not about building a source code repository in a university.

Alex posted this presentation to our group’s mailing list a while back. If you are a developer or work with developers, it will mean something to you. Take a look and then read on.

Github are one of a few companies that talk openly about how they organise themselves and their work. Valve (cf. their Handbook – PDF), Automattic and 37signals are similar examples of how technology companies are both using and building technologies to change the way they work and the way they understand the role of work in our lives. When I watch presentations of enviable working environments like Github, I try to think of how it translates to working in a university, which in many respects also offers an enviable working environment in that academics at least, manage our own time, pursue our own interests, receive decent paid holidays, a pension, full pay while sick, etc. etc. There might be aspects of university life which we complain about, but relative to most other work, it is good work. I enjoy it and on the whole find it very satisfying.

In LNCD, we’ve been watching companies like Github for a while now and have been trying to learn from them and put their approach to work into practice. It is not easy and, off the top of my head, here are a few reasons why:

  • It is not a case of companies like Github employing an ‘agile methodology’, there are significant structural differences between technology startups and large institutions, too.
  • Github is a relatively small (108 employees) company compared to a university, which in our case has over 1300 staff and 12,000 students.
  • Github offers a single service (github.com), which although comprises a large number of underlying technologies, provides focus and direction for employees. Such narrow focus could grow dull over time, but I’m sure that the scale of growth (1.9m users over 4 years) keeps things interesting and challenging and during that time new complimentary technologies have been introduced which they have leveraged (e.g. configuration management software like Puppet).
  • Github appears to be a rapidly growing, dynamic company that currently works on a 1:17500 staff:customer ratio. Their customer-base is technologically savy and so they no doubt benefit from fast and valuable feedback, which drives the product forward. They release a new version of their product/service between 20-40 times each day.
  • A university’s focus is broad, loosely arranged around the themes of research, teaching, learning and enterprise. ‘Education’ doesn’t sum it up. I can’t think of a word that does. Sometimes universities focus on ‘the student experience’ or ‘research excellence’. Within these themes there are then multiple disciplines (e.g. Engineering, Arts, Humanities, Social Science), which have their own needs and expectations of the institution that supports them. Traditionally, they have operated quite autonomously and still do at some institutions. Organisationally, they are brought together as Colleges, Faculties, Schools, Departments, Teams and Committees. Perhaps it helps if we think of universities as a federation of multiple organisations. In some ways, research groups are similar to firms.
  • Universities grow quite slowly. They typically require large amounts of land, building work and the staff:student ratio at Lincoln is 1:9, which includes non-academic staff. Communication and ‘feedback’ within a university tends to happen quite slowly, too. We have annual surveys of both staff and students, course evaluations, committees and ways of providing adhoc feedback, but compared to Github, a university is a relative stable organisation and they tend to have a great deal of longevity.
  • Github’s message to other companies who wish to emulate them is ‘automate everything’; that is, where a machine can do the work better than a human, the machine should do the work and that the short-term effort put in to taking this approach will reap rewards in the long-term. This approach frees up the relatively few staff they have to be productive and creative. So far, no-one has left Github to work elsewhere. Employees are not being made redundant because their work has been automated.
  • Github builds the tools it needs to develop as a company. There are a number of examples in the slides above. We use one of their tools here at Lincoln, called Hubot. Github (the product) might appear to be a single, coherent service, but it is built on a great many underlying services which are coupled together. Github (the company) have built the service from the ground up using largely open source technologies and, where necessary, developing their own glue and renting complimentary services such as Rackspace, Campfire and Heroku.
  • Github claims that is has no managers. I am a manger and I can tell you that as far as I’m concerned, the holy grail of management is to be able to do away with it. The problem is creating the conditions that allows this to happen. What might they be?
  • Here are a few ideas off the top of my head: A relatively small company, working on a prestige product, where employees feel fortunate to work and can quickly see the benefits of their work; they are aware that their work matters and that people rely on them; there is a great deal of focus on improving internal communication and automating processes wherever possible; they do not require face-to-face contact to be able to contribute, so they can recruit nationally and internationally without employees having to relocate; despite this freedom, all productivity is logged through version control software, campfire chatrooms, issue trackers, etc. which discourages freeloaders; and employees are encouraged to work on tasks/projects that interest them and might at some point bring benefits to other employees. Interestingly, Github employees regularly open source their project code, which suggests that even with the freedom to hack on stuff of interest, employees are not always required to turn over their IP to the company.
  • There is a culture of innovation in a university – it’s called ‘research’ – but that does not necessarily mean that the university itself as an institution is innovative. At Lincoln, I think that we have been innovative in our teaching and learning strategy and curriculum design, Student as Producer, but this has not yet translated to equivalent technological innovations. Much of the time, I feel like we try to keep up with technological innovations led from elsewhere.
  • Specific institutional innovation groups (e.g. ‘Skunkworks’ teams) seem very rare in higher education. There are Educational Technologists or similar in most universities but their remit is rarely research and development. Most Educational Technologists are regarded as support staff. I find it perplexing that institutions comprising of thousands of people do not typically have a small, dedicated R&D team that are core funded. Over time, the value that such a team could generate for the institution should be far greater than the relatively small cost of running it but it is an investment that may take years to recoup and some of its value will be hard to evidence as it may not result directly in income generation (i.e. patents, grants, commercial services, etc.) Through innovation, such a group could contribute to the reputation of the university as well as overall efficiencies, which are harder to place a value on.
  • Finally, on a more positive note, I think universities could be ideal places to grow future companies like Github. Y Combinator recognised this in its early days, and universities have played an important role in the history of hacker culture and venture capital. It seems quite feasible that universities could become hackerspaces whose work fed back into the transformation of research, teaching, learning and enterprise across the institution.

The university as a hackerspace

Developers at Dev8D
Developers at Dev8D

I spend most of my time working with students and recent graduates. At first Alex, then Nick and Jamie, and in a week or two, Dale and Harry will join us. Dale and Alex are finishing up their final year in Computer Science and work as part-time Developers in ICT Services. Nick, Jamie and Harry graduated last year from studying Computer Science and work with me on JISC-funded projects. They’re all in their early to mid twenties. I learn a lot from them. Sometimes they make me feel old. I’m only 38.

In a year or so, they’ll probably move on to other things. Alex and Nick already have their own company and a business plan. Jamie wants to do a PhD. If I can secure us interesting and useful work, maybe Dale and Harry will stay on for a while longer, I don’t know. I hope they will stay but it needs to be for a good reason otherwise I would encourage them to look for new challenges.

These days I wonder how we (‘the university’) can support young hackers like the bunch I work with. Career progression for  developers working in universities is not great. Paul Walk recognised this as does the JISC-funded DevCSI project, run by Mahendra Mahey. Without their work, which highlights the importance of local developers, I think the HE sector would be a pretty barren place for hackers to commune. No Dev8D, no DevXS, fewer hack days and developer workshops. Along with several other people, I was invited to be on the Steering Group for DevCSI today, which I am very pleased about, and I look forward to working with the project more closely in the future.

There are a few things I’d like to focus on with DevCSI, based on my experience working with young hackers: the first is about how hackers learn. As I see it, this requires research into the history of hacking in universities, the role of undergraduate and graduate students in funded research, from ARPANET to Total ReCal, hacking as a cognitive craft that has its own learning communities and learning environments, that creates tools which help improve the effectiveness of learning and how those tools eventually shape the tools the rest of us use to learn.

The second thing I’d like to focus on, is how universities can learn from what we see happening in hacker culture: new reputational models, fablabs and hackerspaces, peer-production, and new methods of funding. On this last point, I’d like to develop an academic programme that attracted hackers and graduated start-ups. I think the Y Combinator model is a good example of this already happening, where students and recent graduates are receiving a little funding and lots of support, while asking for just a very small cut of the company.

Finally, I’d like to think about how we can break down the distinction between developers working in professional services and developers working on research projects and remind ourselves that we all work in universities: autonomous institutions for research, teaching and learning, and that when companies want to instill a culture of innovation, they often emulate the research culture of universities. I’d like to work towards developers in HE knowing there was the opportunity to be paid the same as professors when they clearly add similar value to the institution, which I think is easily possible. I see no reason why  great hackers  – experienced software craftsmen and women – working in universities shouldn’t be paid £100K or more, just as professors and other senior staff can be. Of course, working in a university, they would teach other hackers, run software development projects, contribute to the strategic direction of the university and produce superb software for the institution, too. Would they be on an academic or a non-academic contract? I don’t know. At that level, I don’t think it matters, but at the junior and middle periods of their careers it remains a divisive distinction that affects people’s aspirations.

Being great hackers, they would attract students that aspire to be great hackers, too. Just as I decided which graduate school to study at based on the reputation of a single professor working there, so young hackers would want to work with and learn from great hackers in universities, even more so if their programme of study included a Y Combinator style opportunity for angel investment.

I’d like to see an academic programme led by experienced software craftsmen with reputations to match, where students from different disciplines spend their degree in a university space that resembles a hackerspace or dojo, working together on ideas of their own under the guidance of more experienced staff, leading to potential angel investment at any point in their degree. Those that don’t get funded, leave with a degree, a valuable experience and a network of alumni contacts. Those that do get funded are given the support they need to develop their work into a real product or service. Sometimes, it might be one that the university would use itself, but not always. Over time, successful alumni would help attract more students to the programme, developing a culture of hackers and successful startups attached to the degree programme.

What excites me about this is that it’s a mixture of what universities always say they are about: research, teaching, learning and enterprise, but it recognises that those processes are changing and that hackers are already developing a model that is replacing these functions of the university: the opportunities for learning, collaboration, reputation building/accreditation and access to cheap hardware and software for prototyping ideas, can and are taking place outside universities, and so they should. However, I think that university culture is still a place where the hacker ethic (respect for good ideas, meritocracy, autonomy, curiosity, fixing things, against technological determinism, peer review, perpetual learning, etc.) remains relevant and respected. A university is a place where people come to learn from each other and we should be creating these new spaces and programmes that recognise the value of developers in universities.

Like any programme of study, work and investment, it needs careful thinking about how to set it up right, but from where I stand, it feels like a gaping hole in higher education that needs to be filled. Do you know of any examples that are already running? A ‘MIT Media Lab lite’ could be close to what I have in mind, but I have no experience of how it’s run and whether it breaks down the distinction between academic and non-academic staff to the extent I have in mind.