2 page accademic paper about CSL work

We're going to this conference:

	http://www.hfoss.org/hfoss2010/
	
	Thanks to Bob Lechner for pointing out that it existed.
	
	Thanks to Fred Martin for pointing out that we'll have better
	conversations if we submit a "poster summary" or "Position 
	Paper".
	
	Thanks to Laura MacNeil for fixing some really ugly bits in the 
	minutes before the submission deadline.
	
	From what I understand this kind of academic paper isn't a 
	competitive thing. Still it was daunting for me. Then again, 
	freshman composition was daunting for me even after the 4th 
	semester of it.
	
	Pasted below is the unformatted paper. It is submitted and the 
	deadline is past, so the chances of fixing problems are slim.
	
	Still, I'd be grateful for opinions.
	
	I'm particularly interested in what volunteer / student coders 
	have to say. Just because a Fearless Leader (TM) says our 
	atmosphere is relaxed and cooperative mean that it is.
	
	####################
	
	INTRODUCTION

	The Community Software Lab's Open Source software drives two 
	websites: MVHub.com and the NorthShorePort.org Every month, we 
	provide more than 1,000 referrals to services like homeless 
	shelters, pregnancy testing and food pantries. We are working to 
	make our software usable for other sites and other 
	organizations.
	
	Our project has worked with student coders for 7 years.
	
	However, our goal is better software not education.  We help 
	people learn not because we care for them, but because learning 
	helps them write better software for us and we don't have the 
	money to pay experienced coders. Right now hours invested in 
	mentoring return roughly the same amount of good code we could 
	have gotten by spending the time writing it ourselves.  We hope 
	to do better.
	
	Our continued commitment comes from our hope that:
	
	1) Improving our structures will make good student code easier

	2) Improving our structures will make good code from everyone
	    easier

	3) Involving students will help our broader social goals.
	
	Most significantly, since last year, We've moved from spending 
	80% of	our technical time in system administration and web 
	hosting to spending 90% of our technical time on software 
	development. It is also our hope that this narrower focus will 
	yield better results.
	
	EDUCATION IS NOT OUR GOAL

	We are not an educational institution.  If the field of software 
	engineering education improves and our project doesn't have 
	better code, we have failed. Our learning and teaching is 
	radically different from that of educators. We learn what we 
	need to know to solve our current software problem cleanly. If a 
	student is working on a problem, we do just enough teaching to 
	help them over the hump. 
	
	Student Code Is of Low Quality
	
	Students write code that will be used only once, late at night 
	by a sleepy graduate student grader. The simple rules of craft 
	do not apply.
	
	The test data will always be in the same directory as the 
	executable and the executable will always be run from its 
	directory. Checking the result code for "open" is not required.
	
	It is a solid satisfaction to share our craft and see somebody 
	else's contribution increase. This pleasure is diminished 
	because as peoples' skills increase, so do their odds of getting 
	a paying day job and leaving us.
	
	OUR CURRENT STRUCTURES

	At any time, we'll work with anyone who can figure out how to 
	pull a bzr branch from http://launchpad.net/mvhub/ and submit a 
	patch to us.
	
	We have 6 spots for local volunteers willing to commit 4 or more 
	hours per week in our office. When a spot opens up, we accept 
	anyone who can do the very simple coding test at: 
	http://thecsl.org/go/vol/
	
	When a new volunteer arrives, we toss them the "Learning Perl" 
	book.  In about 2 weeks, most people report back that they've 
	learned enough Perl to get started. We help them setup an 
	account on http://launchpad.net, create an account on our 
	servers, and do a brief run through of bzr version control 
	software and launchpad bug tracking.
	
	For the first project we'll sit down together, go over the 
	problem & create or update the rough written project notes/bug 
	report.  For example: 
	https://bugs.launchpad.net/mvhub/+bug/394833
	
	We usually have somebody with a little more experience who can 
	share a keyboard with the new volunteer for 25% to 75% of the 
	time. Often we can assign two new people to the same problem.
	
	IMPROVED STRUCTURES

	Right now, we usually don't evaluate volunteers performance or 
	learning until potential employers call to check a references. 
	(We do constantly review & evaluate code) We don't make any 
	serious effort to keep to the milestones we've set. Projects are 
	often selected and defined based on whatever is floating on top 
	of our stream of consciousness with the primary selection 
	criteria being appropriateness for beginners.
	
	Learning is "just in time" and ad hoc and closer to tutoring 
	than instruction. We avoid the difficulty of installing our code 
	by creating a tidy development environment on our servers.
	
	Our current approach has the big advantage of creating a 
	relaxed, cooperative atmosphere focused on doing good, slow work 
	rather than quick, sloppy work.
	
	Because we depend on pairing experienced and inexperienced 
	programmers, we are bottlenecked by our limited supply of 
	experienced programmers.
	
	Because our documentation and training is often "just in time" 
	and our code is easily run only on our servers, it is difficult 
	for people outside Lowell Massachusetts to contribute to our 
	efforts. While a relaxed atmosphere helps learning, potential 
	funders our software seem to prefer well defined deliverables 
	and a well defined time-line for delivering them.
	
	To address these difficulties, we intend to improve our training 
	materials for the tools and libraries we use beyond Perl itself, 
	improve the packaging and installation of our software and work 
	harder on feature definitions, time-lines & milestones.
	
	BROADER GOAL / PARALLEL HABITAT FOR HUMANITY
	
	The public perception is that Habitat for Humanity's uses 
	unskilled volunteer labor to build simple decent houses for less 
	than the cost of paid professional labor.  From my 7 years 
	working in the IT dept of Habitat for Humanity International and 
	continued involvement as a volunteer at the local level, I know 
	this is not the case.
	
	Dividing the amount of money raised by the number of houses 
	built, Habitat's amateur builders at best accomplish the same 
	cost efficiency as professional builders. Unskilled volunteer 
	labor is unpaid, but requires either re-work or behind the 
	scenes staging and setup. These costs don't go away for being 
	hidden.
	
	This does not mean that Habitat for Humanity has failed, their 
	goal is to make simple decent housing a matter of conscience. 
	The important part of building houses is the effect it has on 
	the builders.
	
	Making useful and reliable FOSS is our short term goal. However 
	our long term goal is to help change world culture to include 
	the free software values of transparency, meritocracy and 
	generosity. We can't make our long term contribution by telling 
	people to be more transparent, generous and fair. We can only 
	offer people the chance to indirectly develop these values by 
	their volunteer effort.