by Evviva Weinraub Lajoie, Trey Terrell and Mike Eaton

Introduction

Since 2012, Oregon State University Libraries & Press (OSULP) has worked to train all of our technology student employees on how and why they should engage in Open Source community development. We’ve spent a tremendous amount of time and effort on creating a strong, structured, educational program for our students that empowers them to engage successfully not just as developers, but as contributors to open source communities.

We participate in open source development because it allows for tremendous flexibility and customizability as well as allowing all members of the staff to have a say in how the patrons use and interact with the library. What perhaps differs at OSULP is that, as a land-grant institution, one of our core missions is outreach and support for the communities within the state of Oregon. Oregon State views sharing our research and ideas as an integral part of that outreach. This participation also empowers staff members to feel that their work is contributing to a larger world than the confines of the building.

This article will outline the structure of the Emerging Technologies & Services Department (ETS) at OSULP, some of the resources we have, how we hire students, and what we offer them in terms of training. Then, we’ll move on to talking about the benefits, both tangible and intangible, the students who work with us receive. We’ll then talk a bit about what we have viewed as necessary to build or promote as part of building a culture of open engagement and finish with the reasons we find this model effective.

Resources

Staffing

The development team at OSULP consists of:

• Four analyst programmers of various competency levels who do a variety of web development activities
• A digital application librarian (tenure track librarian)
• A repository product owner (tenure track librarian)
• Four student web developer positions available within the department ranging from freshman to seniors with an occasional graduate student in the mix

Most of the development work we do is in Ruby on Rails, PHP, and Drupal. Our staff and students provide all of our web development and application support, create custom applications, work on infrastructure, and contribute to larger open source communities like Hydra and Fedora.

Development Environment

OSULP supplies computers and software to our student employees. We have pretty standard Dells with adequate RAM (8 GB) and disk space to work on a variety of projects quickly and efficiently.

As we mostly develop Ruby on Rails applications, the standard environment consists of the following tools:

• Linux Mint
• Git
• T-mux for terminal pane switching
• Vim with associated plugins for syntax highlighting, running tests, Git management, and code navigation.
• Ruby language binaries
• rbenv for switching between ruby versions ( https://github.com/sstephenson/rbenv )
• System dependencies for common Ruby gems

Open Source Policy

While OSULP had been developing almost exclusively with Open Source tools for years, in May, 2013, we officially passed an Open Source Development Policy (http://library.oregonstate.edu/ets/guidelines). In our minds, having a written policy made a clear statement that we felt that Open Source development was in the best interest of the library, the university, and the profession. It aligns with the library’s core values of access, collaboration, and service as well as the university’s position as a land-grant institution.

When writing the policy, we spoke honestly with our student employees about why we were writing the policy, and one of them said they thought it was a really good recruitment tool with potential students. It wasn’t just because they’d graduate with experience working on development projects, but that every project they worked on provided them with an opportunity to participate in something bigger than themselves. For them, that was inspiring, and spoke volumes about us as an organization whose approach would be open first.

Students & Expectations

Finding the Right Candidates

Like many departments, our search for the right candidate starts with a position description.

We advertise on the student job board, send out notices on the College of Engineering’s Listserv, and market directly within the programming classes offered in the College of Engineering. This last one is a bit unconventional, but it came about for two major reasons. One: the library’s faculty are tenure track, which means they are required to do some sort of teaching in order to achieve tenure. Two: the programming languages most often taught in our College of Engineering are primarily languages for programming hardware. Both our Digital Applications Librarian and our Analyst Programmer have taught classes on web development, Ruby, and Linked Data/RDF which gives us direct access to students and strong ties with faculty who can push promising developers our way.

During our candidate interviews, students are asked to perform a logic test. The idea is to have the student walk you through their thought process and how they would go about fixing a problem. This gives you a good idea of how they would approach working through tasks and projects you assign them. We have had students with multiple development projects under their belt interview and do poorly on our tests, while people who have only ever created a website in their high school computer class do phenomenally well and become very good programmers.

According to books like The Confidence Code: The Science and Art of Self-Assurance—What Women Should Know and Lean-In, women are less likely to apply for positions for which they are not 100% qualified. Our approach helps lower the barrier for many potential programmers to learn and thrive as there is no expectation that students come in with all of the answers.

Recruitment

It’s important to remember when you’re working with students, especially developers, that they have many options available to them across campus. Most departments have some kind of programming job they need done and if you string enough small jobs along, you can make pretty good money.

Because you are fighting for a finite resource, you need to make your space somewhere they want to be, and make sure you are offering skills and experience they can’t get either on their own or with another department.

In the case of OSU, we have two other units on campus that have significantly more money than we do and despite the fact that we are supposed to hire students at the lower end of the ranges provided to us through HR, these departments don’t always play by the “rules” and pay their students more money than we can. We’ve had to become creative. When students come in, we walk them through the intangible benefits of working with us. We explain what kinds of training we offer, the kinds of projects they’ll get to work on and we make sure they understand that they will have the opportunity to start and finish a project, allowing them to work through all phases of the project, from initial conversations with the product owner, to the post-launch party.

Educational Initiative

OSU Libraries & Press launched our current strategic plan (http://osulibrary.oregonstate.edu/flipbook/strategicplan/) in 2012. Within the plan, goal 2.2 explicitly talks about delivering experiential learning opportunities to students. There is ample evidence to support the idea that experiential learning opportunities offer phenomenal value to students, both during their tenure at your institution as well as post-graduation. Even if we didn’t have a specific goal outlining the library’s commitment to providing experiential learning, we would have organized our program much the same way.

Over the last two years, we have created a series of learning outcomes based on the job categories we have within the library. Each student goes through an annual review process, much like our regular employees. Within their first week of employment, we set up a meeting to create learning and stretch goals with them. During this meeting, we set up a three month review to discuss how they are doing, what’s working and not working, and where they are in the process of accomplishing their goals.

Near the end of the school year we perform annual evaluations of students, similar to the annual evaluations of regular employees. Assuming the student employees are doing good to excellent work, we offer a modest pay increase. We ask our students to write up a self-evaluation of how they think they performed over the course of the year, what they learned, what they contributed to, and how their work contributed to the library’s strategic goals. We then provide them with a write up, and a meeting where we discuss their progress and accomplishments over the year.

In addition, we provide the students with a transferrable skills document (see Appendix A, below) that they can use to help write their resume. It clearly outlines what skills they have learned and used while employed with us.

This approach really goes far in not only teaching your students what to expect when they go out into the workforce, but gives them an opportunity to see their work in the context of the entire organization and the impact that work has.

Mentorship

Mentorship is key to building successful developers and we work very hard to provide a true mentorship experience for our students. While we make sure they know they can ask anyone anything, they have an assigned mentor to whom they can turn if they have any issues, need help finding training, or just need someone to bounce ideas off of.

Part of what we’re teaching them is good development practices. We have found that using GitHub pull requests are an excellent point for collaborative code review and training and a real opportunity for facilitating mentor/mentee communication. We also encourage peer mentorship by having the students use the GitHub pull requests to check each other’s work.

Additionally, our students also know that they can reach out to their mentors if they run into issues with programming class work. This is especially valuable when students work on their senior capstone project.

Library Alumni

We feel strongly about teaching them the skills they’ll need to do the job we’ve hired them to do, offering them a support structure they can depend on, working to create a positive, educational experience, and arming them with the tools they’ll need for work post-graduation. This is a lot of effort, energy, and expense to put toward your student workforce, but it’s a move we’ve made comfortably because we’ve reframed the way we view our students. We no longer look at them as a cheap labor force, hired to backfill time and make new pages in Drupal; we look at them as our alumni. We view our graduating students as part of our family, and we strive to give our students the best skills possible. In the case of our department, this has meant a 100% post graduation employment rate for all of our students.

The work our students do with us not only helps them to create a work history, but it teaches them good work habits. Your students are committing code not just under their own names, but in the name of your institution, and it’s important for them to understand that they are representing not just themselves with every line of code they commit, but the larger institution. People respond positively to that kind of trust being bestowed upon them, and take your commitment to them seriously and professionally.

If they leave knowing how to collaborate, how to build test-driven code, how to review code, and feeling confident when they commit that code, you’ve been successful. But it won’t be hard for someone to figure out where a developer learned their bad habits. That’s not a reputation that you or your institution wants. Especially if you start viewing your students the way that we do, as future library alumni.

Training

We cannot stress enough the importance of supporting training costs for not just your students but your staff as well. We have created a curriculum for our students to follow, and recently, when we hired a new developer who had no experience working with Ruby, they followed the same curriculum to great success.

We purchase access to Code School, Railscasts, Code Academy, books, etc. We budget approximately $1,000 – $2,000 a year for these kinds of tutorials for both students and staff.

Students are paid to learn and to keep their skills up. We do not expect them to come in with every skill we need; in fact, in most cases we prefer they don’t. We expect that we are going to teach them the skills to do the work we need, and to learn good habits they can take with them to positions post-graduation. As stated earlier, we often hire students who have played with HTML and have great logic skills and then teach them everything they and we need rather than expecting expertise right off the bat.

It takes our students about two months at 40 hours a week to get up and running. By the end of that time though, they are designing tests and building applications. This approach requires a lot of work and effort on our programmers up front, so it’s important that you make every effort to protect their time during training periods. But because we all view the training work we’re doing as part of our departmental, library, and university mission, it’s easier to make the case for its importance.

Keeping them Happy

The thing to remember with many of your students is that this may be their first job, so it’s important to think about what you expect of them. On their first day every one of our students gets a sit down with the department head where they outline their role, what they expect of the student, and what they can expect to take away from their time with us. We have had student employees who thought it was okay to take their shoes off, put their feet up on their desk, and walk barefoot around the office. These are things that may seem obvious to you, but aren’t necessarily to your students.

Again, the expectation discussion is as much about what you’re promising the student they will get out of their experience with you, as it is about what you expect from them. We have found that this brief 5 – 10 minute “get to know” you session breeds trust on both sides, and sets the student up for success later on. This meeting helps with accountability as well; we have very low rates of absenteeism with our students and having that initial meeting really helps set expectations for professionalism.

We work with our students on their schedule. We have found that some of our students end up coming in to the office even when they aren’t working because they like the space, they feel comfortable here, etc. If you find that to be the case, it’s important to remind them that this is still an office, and even if they aren’t working, others are.

Just like our full-time staff, we also try to take all new employees out for lunch or coffee on their first day. It’s a nice welcome to them and gives them a chance to chat with their colleagues and mentors in a more informal setting. It’s a good cultural dunking.

Empowerment to Engage in Open Source Communities

Even before we wrote our Open Source policy we were using GitHub for version control and source code management, so we have a history on GitHub with a large number of projects.

Because our students get to participate in projects from beginning to launch and beyond, they get to build up a GitHub profile. As more and more job ads ask for examples of committed code, or for links to GitHub profiles, you’re offering your students a portfolio of work they can use to get a job post-graduation.

Through their work, we’re teaching them about Open Source communities, code repositories, and encouraging engagement in those communities. This indoctrination, if you will, helps set them up to look for postgraduate positions that work in the open source arena. We’re not going to tell you that your students are necessarily going to work for cultural heritage institutions when they graduate–many of them are more concerned about paying off student loans than the type of institution they will work for–but providing them with experience in open source communities will nudge them toward open work in general, because they have significant experience with those environments.

Institutional Commitments

Community Building

We work hard to create a sense of community with our students and actively encourage them to participate in a number of activities and opportunities provided across campus.

There is a weekly stand-up meeting with the staff and our students are encouraged to attend if it doesn’t conflict with class schedules. This give them an opportunity to not only feel like part of our community, but again, to see their work in a larger context.

We have a weekly cross-campus web developer meeting. These used to be based around a specific language or tool, like Ruby or Drupal, but have been broadened to include anyone doing web development. This also helps to build a sense of community, to help the students learn about how development is done in other departments, to give them an opportunity to see what kinds of work they could do post graduation, and provide a forum for sharing issues, thoughts, and ideas.

We try to schedule regular hackathons, at least once a quarter if possible. We buy some coffee, make some cookies, and pay our students to sit around in a room, toss out ideas, and build whatever they want. We think it’s important for them to be able to engage in this kind of creative process. You never know what may come of their time.

Again, we make a tremendous effort with our students to help them integrate into our culture, to integrate with our staff, and to feel part of the larger institutional community. We also work hard to help the students engage and integrate into the larger Open Source community, while providing a safe place for exploration.

Intangible Benefit

As our students represent our institution on the international stage, they have a real sense of ownership as their work can be judged by anyone at any time. This is a heady responsibility for them, and all of our students recognize their contributions and have pride in what they put out into the world. They are confident that the work they are doing is good, because we make sure it is. Our goal is not to have a cheap workforce supplement what our full-time staff doesn’t have time to accomplish.

These kinds of intangible benefits are communicated to our potential student employees when they interview with us. We sometimes lose out on a great student because we can’t pay them, but the ones who choose to make a little less money all say that they think the benefits they’ve gained here are greater, and the impact their work has is larger, than elsewhere. And that’s pretty phenomenal feedback to receive.

Administrative Cost

What’s necessary to build this kind of support structure at your institution?

Your biggest cost is going to be the students themselves. We will often hire students with lesser skills, both because they cost less, and because we can teach them good habits. But even still, students can be expensive, so it pays to get creative.

Other than applying for small campus wide grants for various projects, we also do small projects for Central IS, the graduate school, or a faculty member with some money and an idea for a class. These small projects may only bring in a few hundred to a few thousand dollars per project, but they can help offset costs, and buy more time for your students. In our case, this has become an even bigger potential source of funding since our Central Web group recently stopped all non-Drupal development, but you need to be REALLY careful about scope creep and spending too much time on non-library work.

As far as administrative support goes, there are two sides to this coin. We sometimes ask our students to present a project or do a demo of a new tool at our administrative briefing sessions. We ask them to write short articles for our donor magazine, and they will occasionally be asked to speak to our library advisory council. While these tasks are not specifically programming, they are paid for their time. This provides them with an opportunity to talk about their work, and represent the library.

Earlier this summer, our students helped out with a weekend long event designed to help high school aged girls begin to program and work with technology. The students are invited to lunch with the rest of the staff on a regular basis, and the director will often bring cookies, chocolates, or other small gifts back from trips to let them know their work is appreciated. Again, this comes down to making them feel like they are part of the larger culture of not just the projects they work on or our department, but the institution as a whole.

Conclusion

We hope we’ve made it clear that there is a lot of work involved in training the next generation of Open Source contributors. There are four key factors we think to make this a successful model.

You have to be intentional about creating a supportive infrastructure. Your institution needs to be open to allowing people to learn on the job, and support them in their learning efforts. You also need to make sure that those that are working directly with your students understand your vision, and are willing to spend their time doing this work.

You must provide proof that you support open culture. This is about open communication, but it’s also about putting your money where your mouth is. In our case, we created an open source policy to announce to the world that this is how we do business. This fits into OSU’s role as a land grant university and sharing is fundamental to what libraries do, so it’s a straightforward decision for us, but may not be as simple for other institutions.

You must train and provide mentorship to your student employees. While this is a financial burden, the return on investment is well worth the costs.

You must acknowledge your limitations, and need to be honest with yourself about what you can implement, allocate and invest in the process.

Many institutions with fewer resources than we have at our disposal, can still implement portions of what we’ve outlined and see tremendous success. Investing in training for students, however you choose to support them in your workplace, can pay back the institution with loyalty, innovation, and community participation.

Acknowledgements

Special thanks to Rick Stoddart (now at the University of Idaho) for working so closely with our department to create learning goals that meet the unique needs of ETS’ future alumni.

About the Authors

Evviva Weinraub Lajoie is the Director of Emerging Technologies & Services at Oregon State University Libraries & Press where she works on digital publishing, mobile, and open source tools development.

Trey Terrell is an Analyst Programmer in the Emerging Technologies & Services department at OSULP. He works on research and programming for web-based projects.

Mike Eaton is the UX Manager in the Emerging Technologies & Services department at OSULP. He is responsible for project management and the user experience. He is also a recovering developer.

Appendix A

Student Assistant Contacts & Transferrable Skills