Project management and bundling dependencies

Question

I've been looking for ways to learn about the right way to manage a software project, and I've stumbled upon the following blog post. I've learned some of the things mentioned the hard way, others make sense, and yet others are still unclear to me.

To sum up, the author lists a bunch of features of a project and how much those features contribute to a project's 'suckiness' for a lack of a better term. You can find the full article here: http://spot.livejournal.com/308370.html

In particular, I don't understand the author's stance on bundling dependencies with your project. These are:

== Bundling ==

• Your source only comes with other code projects that it depends on [ +20 points of FAIL ]

  Why is this a problem, especially given point 3, that you have modified your projects dependencies to fit your project's needs, doesn't it therefore make even greater sense that your code should be distributed with its dependencies?

• If your source code cannot be built without first building the bundled code bits [ +10 points of FAIL ]

  Doesn't this necessarily have to be the case for software built against 3rd party libs? Your code needs that other code to be compiled into its library before the linker can work?

• If you have modified those other bundled code bits [ +40 points of FAIL ]

  If this is necessary for your project, then it naturally follows that you've bundled said code with yours. If you want to customize a build of some lib,say WxWidgets, you'll have to edit that projects build scripts to bulid the library that you want. Subsequently, you'll have to publish those changes to people who wish to build your code, so why not use a high level make script with the params already written in, and distribute that? Furthermore, (especially in a windows env) if your code base is dependent on a particular version of a lib (that you also need to custom compile for your project) wouldn't it be easier to give the user the code yourself (because in this case, it is unlikely that the user will already have the correct version installed)?

So how would you respond to these comments, and what points may I be failing to take into consideration? Would you agree or disagree with the author's take (or mine), and why?

Edited for clarification.

Answer 1

Your source only comes with other code projects that it depends on.

My project requires project X.

However, since my project depends on secret inner mysteries of X, or a previous release of X, then my project includes a copy of X. Specifically release n.m of X. And no other.

Try to install the latest and greatest X and see what breaks in my project. Since upgrading X broke my project, forget my project. They will not struggle with something that spontaneously breaks after an update. They will find a better open source component.

Hence a FAIL score.

If your source code cannot be built without first building the bundled code bits.

My project doesn't rely on the API to X. It relies on deep, inner linking to specific parts of X, bypassing the API.

If my project on depended on the API to X, then -- for some languages like C or C++ -- my project could compile with only the C or C++ headers, not the binaries.

For Java this is less true, since there is not independent, non-binary header. And for dynamic languages (like Python) this makes no technical sense.

However, even Java and Python have ways to separate interface from implementation. If I rely on implementation (not interface), then I've still created the same essential problem.

If my project depends on C or C++ binaries, and they build things out of order, or upgrade another component without rebuilding mine, things may go badly for them. They may see weirdness, breakage, "instability". My product appears broken. They won't (and can't) debug it. They're done. They'll find something more stable.

Hence a FAIL score.

If you have modified those other bundled code bits.

I have two choices when I modify X.

1. Get it accepted as part of X.

2. Fix my program to work with unmodified X.

If my project depends on a modified X, no one can install X simply, correctly and independently. They can't upgrade X, they can't maintain X. They probably can't apply bug fixes or security patches to X.

I've essentially made their job impossible by modifying X.

Hence the FAIL score.

Subsequently, you'll have to publish those changes to people who wish to build your code.

Actually, they'll hate me for that. They don't want to know about the mysterious changes to X. They want to build X according to the rules, then build my stuff according to the rules. They don't want to read, think or be sure that the mystery update patch kit was applied correctly.

Rather than joke around with that, they'll download a competing package. FAIL.

if your code base is dependent on a particular version of a lib (that you also need to custom compile for your project)

That's really shabby. If I depend on a version with custom compiles, they're done looking at my package. They'll find something without version-specific inner mysteries and custom compiles before they'll struggle. FAIL.