Developer Registry: Ben O’Steen

Feb 17, 2011 by kirsty-pitkin

O’Steen began the session with the question: “What the hell is a Developer Registry?”

He recently blogged about the need for a system which enables you to find out what your peers are doing and how to find people who have the skills that you need. There is often bespoke, custom, but low usage of certain pieces of software, which means there is very little shared experience and information available about particular products. Contacting someone who has used that software before could save hours of work.

O’Steen suggested scraping Github and PIMs and various other places to get a profile of each person, including the projects they have worked and the code they have put out, so you would not have to rely on people publicising their skills in the most appropriate way for them to be identified. It would require submitting usernames for these services so that the publicly available data can be mined.

He then opened the session up for ideas from the group as to how we could make such a resource happen. Comments included the benefits of promoting developer time swaps between institutions as a way of increasing developer impact, and the increased strength of research bids to organisations like JISC, who often reject bids because the necessary skill sets are not available at the bidding institution and there is no indication in the bid about how they intend to overcome this.

The group all felt that it was fundamentally good idea to have such a directory of publicly available information. George Kroner from Blackboard discussed some of their experiences solving a similar problem across their wide developer base, where they have examined ways of linking people through existing networks rather than building a separate networks, which then require support. They also used Google Maps to get developers to put in a flag for themselves and list their projects. O’Steen agreed that this was an attractive option for making connections within the developer’s local area.

The group also discussed the carrot aspect of the project and ways of incentivising people to opt in, which could include a LinkedIn group to discuss the value of the system. They also discussed the option of a credit system or a day bank of developers, or an advertising site where developers could bid for small pieces of work, as in the commercial sector. Members of the group observed that this would be particularly useful for developers who go freelance after working in HE. Further suggestions included the Google internal model of peer reference rather than self-promotions.

The session concluded by considering how to sell the idea to institutions and the barriers that may be faced in moving forward. They suggested using the university secondment system, which would involve gaging whether institutions could be agile enough to do this for short periods of time. They also raised issues about IP within contracts at some institutions, whilst others have an option for employees to provide consultancy on the side. Others observed that the existence of a profile within the database may not imply that people can actually get permission from their employers to do a time swap at a particular time, so the issues could be kept separate. Creating the database to know who to ask a question about a particular tool would be the most achievable thing in the short term, whilst in the longer term considering the more complex issue of swapping staff between institutions.

O’Steen offered to draw up a picture to demonstrate what this could look like to get the ball rolling, whilst others would discuss the ideas internally to define the barriers and consider solutions.