What’s the opposite of open source hacking?

I recently read Chris Tyler‘s paper, “A Model for Sustainable Student Involvement in Community Open Source”. Chris writes:

To effectively teach Open Source, it’s necessary to move each student into the role of contributor. At first blush this appears straightforward, but it ultimately proves to be an enormous challenge because Open Source is as much a social movement as a technical one and because many Open Source practices are the exact opposite of traditional development practices.

I like this paragraph, but something struck me as not quite right about it.  Open Source practices don’t really feel like the opposite of traditional development practices to me.  What I think they’re the opposite of, actually, is homework.

If your programming experience is limited to homework assignments, working on a real-world software project is going to be overwhelming for you, whether it’s open source or proprietary—and for the same reasons.  You’re used to writing small programs, individually, completely from scratch.  The software companies I’ve worked for all had teams of developers working cooperatively on a large, existing codebase, with version control, complex build systems, not enough tests, bug trackers, thousands of known bugs, good code, bad code, and way too much of the stuff for any one person to understand.

Did I mention working cooperatively?  Traditional software development really is supposed to be done that way, I promise.  Well, maybe it depends on where you work.

Later, Chris writes, “[E]ven students who don’t continue working with Open Source take an understanding of Open Source into their career, along with an understanding of how to work at scale — which is applicable even in closed-source projects.”  That’s the stuff!  Open source development is different.  But it’s not that different.

4 Responses to What’s the opposite of open source hacking?

  1. I don’t want to be harsh, but clearly it’s been a long time since you did any homework. More often than not, when you get coursework in Computer Science programs, you’ll be required to work in groups. I’m currently doing an “Advanced” Software Engineering course, which deals with maintenance, tests, refactoring, yada yada, and one of the coursework assignments is being given a fairly large java project, and being told “don’t change any functionality, but improve the code” (in groups of 3 or 4). Using VC is “strongly recommended”. Said code has no unit tests (only functional ones, which require so many magic incantations that nobody in our class has gotten them to run yet, to my knowledge). It has duplicate code and broken architecture (cyclical dependency) issues. We write reports on a wiki. We do profiling analysis on existing projects. Etc. Etc.

    Of course, you can give homework in a way that doesn’t teach you anything – but that’s a fault with the particular homework, not the concept of it.

    Finally, there’s a “crawl before you walk” thing going on as well: if you can’t write code from scratch, don’t even think about trying to adapt someone else’s code in a Good way.

  2. Yes, I agree – in most regards, open source and closed commercial development have quite a lot in common. In either case, you’re going to have multiple developers getting in each other’s way, which in turn creates the need for a variety of infrastructure – version control, bug tracking, robust build scripts, automated tests, continuous integration, etc. They need to be able to communicate well, and generally, to keep track of what the rest of the team are doing.

    There are exceptions, but student coding projects rarely bear any resemblance to this. They’re usually small, so they never need to deal with growing complexity, all the things like bug tracking and automated testing that become important with complex systems. And they’re usually working on their own, so they don’t need the skills of working as part of a team. In short, they’re fine for teaching pure coding, but entirely unrealistic for teaching *development*.

  3. I actually think we’re in agreement 🙂 The “exact opposite” phrase primarily applies to maximum sharing vs. maximum secrecy of source code.

  4. It likely also depends on the scale of the project – I’ve worked on some smaller software projects where the entire team consisted of me, a DBA and the QA guy who was pulling double duty as our UI engineer. In this case it was pretty similar to homework assignments in university, even though it was at one of the world’s largest software companies.

Leave a Reply

Your email address will not be published. Required fields are marked *