SquaredPegBrad J Ward’s Thoughts on Higher Education Recruitment

Leveraged correctly, open source applications can be an extremely positive and effective portion of your overall business processes.  The tricky part is finding balance, and being able to quickly determine the cost/benefit of the open source project.  For instance, you have an application on the cutting edge of technology.  It’s got amazing features, features you don’t necessarily need- but wow are they cool.  The back-end is sort of complicated and your programmer is having a hard time getting the technology down, but you being the big-picture sort of person can see the potential. 

Back up a second.  What other open-source technology are you using?  Is this another application that has a huge learning curve and will constantly need tweaking?  What benefits do you expect, or even hope to realize from this application?  Do you know anyone or have heard about anyone successfully implementing this application?  If so, have you spoken with them?

Yeah, I know…I’m starting to sound like the stuffy old admission administration, but in this case (and many others) the “old school” is on the right track.  Use caution when implementing many different open-source projects.  I’m not against open-source, it’s what drives the Information Technology industry to bigger and better things.  I am against putting all of your technology needs into open-source when you cannot guarantee the same level of support, documentation, and quality from application to application.  Now I realize you can’t exactly count on quality and consistency from non-open source applications, but you can usually count on a consistent support structure, consistent documentation, and a community of some sort to go to with questions.

How do I “Leverage open-source projects“?

-First of all, ask your programmer.  Have them take a look at the documentation, the technology behind the scenes, to get a preview of what they will be working with.  If they have reservations at that point, that should throw up red flags. 
-Call around, and see if you can track down people who have used the technology (heck- you’ll be increasing your network at the same time) and ask them about it.  Did they have any implementation issues, any support issues?  Ask if the return they’ve gotten from the project has been valuable.
-Use-ability testing is your friend.  You don’t need thousands of users testing to be successful.  Actually in this case 5-10 will do nicely.  Simply ask them what they think is important about your application.  Ask them if they think it is necessary, or if it’s “cool”.  If your goal is to get them to sign up for a forum, to interact with a community – ask them if they want to.  It’s all about the users, so make sure they actually want or like what you are adding.
-Very specifically lay out your expectations and goals for the application.  If you find you’re at a loss to define very many things (“because it’s cool” is probably not going to cut it) – again flags need to be thrown.

Open source is, and can be very cool.  Keeping your programmers sane, and free to work on high value projects is “way cooler“.  It’s your job to make those tough decisions – so make sure you find value to go with ”cool”.