The BuildOrBuy decision troubles many companies. If you buy, you are stuck with features and complexities that you don't need, due to all the extra indirection the vendor has to put in to cater to everybody. However, if you build, you are reinventing the wheel from scratch.

It seems to me some kind of compromise is in order, but I don't see many companies providing such. I envision "kits" that maybe provide two sample applications: a simple one and a full-featured one. The customers then take bits and pieces from each as needed, and reprogram stuff for special needs. The downside is that upgrades can be tricky because you may have to rework custom changes into the upgrade. But adapting piecemeal may still be better than adding from scratch. After all, adding new code (outside of kit supplier) is still an option, thus you cannot be worse off.

-- top

You don't seem to have noticed that your brainstorm requires the entire problem of "reusable software" to have been solved first. Since that isn't even a little bit close to solved, what you are suggesting is not actually feasible -- unless perhaps you got a lot more specific about some software area where reusability '''has''' become a partially solved problem. Spreadsheet templates, perhaps. :-S -- DougMerritt

''No, only half-solved. It's almost like buying the source-code to a specialty application so that you can modify it for your org's own needs, except that the source-code would be designed with extendability in mind. The internals would also be well-commented and well-documented.''

AnonOther notes: You mean like codecs in media players? Or Plugins in many different programs, but I'll give as examples EclipseIde and FireFox.  I can envision some IT department removing esterotic_feature_6 out of MsWord which allows it to run on the aging systems, and isn't used i the organization.  (Although Word would be more of a "Buy Minus" as apposed to a Kit.

''Codecs are more along the lines of SystemsSoftware. I'm thinking more of industry domains, like food cargo tracking.''

I agree that there can be lots of room for middle-ground between complete make or buy decisions. This can be one of the differences between a programming framework and a product. Some examples from the .NET programming world might be WF4 (Microsoft Workflow Foundation 4.0) and open source projects like MassTransit ESB, Rhino ESB, or NServiceBus. These are basically tool-kits or frameworks that a programmer can leverage. Several features in these frameworks overlap with several features from products like Microsoft BizTalk. However, some may consider BizTalk to be both a product and a framework.
However, as a programmer I would prefer a framework that did not lock me in too much by requirements from a product's architecture or by too many dependencies on its facilities. I would rather pick and choose the best components of a framework, in an a' la carte fashion, based on my own preferences.


---- 
CategoryReuse