Ah, the joys of reuse... but beware of productization

After I have decided to go for the localization tool (I find it difficult to blog about it without having a proper name for it first—usually, apart from my dubious company name, naming is not one of my weaknesses), I moved a great deal of the codebase of my other product development into a separate DLL for reuse. That class library, dubbed AuthorBase, now provides a pretty complete framework to easily and quickly create the scaffolding for an application that has some or all of the following requirements:

• A windowing system that allows for tabbed windows, separated into tool windows and document windows (similar to IDEs such as Visual Studio, Eclipse, or SharpDevelop, although my system does not support draggable or floatable windows—they are merely tabbed intelligently and can be re-arranged within their tabbing container)
• A 'project file'-based work flow, with all kinds of editors for all kinds of file types already built into the framework and easily extensible
• The application can extend the framework in specialized manners only, such as: extending the option dialog by additional tabs / sub tabs / option groups / options, extending the types of projects or items that are supported by the application, etc.
• There are standard commands (such as file, editing and formatting commands) and commands can be sent between tabbed windows
• Properties can be marked up to be persisted to and restored from user settings, this is done automatically on start-up and shut-down of the application
• There are pre-existing, but customizable standard windows such as splash screen, Start, Options, Create New Project wizard, Integrated Web Browser, Project Explorer, Properties and many more to come.

Since these are base features required by both my two forthcoming products, I have just halved the time taken for these base features per application simply by adding another application...  ;)

Both products belong to that strange hybrid application category that is authoring as well as productivity as well as developer tool (but in both cases, also offered to and usable by non-developers alike), so that shared code was the sensible thing to do. It also means that any further innovations (to user interface, usability, or even code-related stuff such as performance or the support of additional standard editors, say) are introduced to all applications utilizing AuthorBase.

A framework is not necessarily a product.

I'll admit it, AuthorBase was once a product idea of mine. Maybe it re-evolves into one, but I didn't go for it because although I saw a need for myself, I found the idea of pitching such a framework to development teams quite scary. That's a different matter with the two products I'm now developing: they, too, address issues that developers or development teams have, but they don't impose a certain architecture on their codebase, they merely offer outside-the-IDE process support to certain "orthogonal" concerns (such as localization) of their jobs.

Trying to sell generalized frameworks such as AuthorBase must be tough, because you are effectively selling a certain approach to application design. For prospective customers, that could be a real gain in time-savings, but there is simply a substantial risk involved: what if the off-the-shelf application design they purchased turns out to be crap? As programmers, how would they know before the market tells them, which would be too late?

In my opinion this is a very real risk that should be taken to heart and addressed by anyone attempting to sell products that essentially revolve around the idea of saving customers time by providing them with a fill-in-the-blanks application design. [1] My framework works for me because I have written it and although in theory generalized enough so as to be reused in third-party applications, my advantage is that as soon as I need an extension, I'll write it; as soon as I encounter a bug, I'll fix it. I know how developers tick: I wouldn't even try to convince them of my architecture by means of mere marketing. Notice the subtlety: they may well be fascinated enough by my upcoming products (or maybe not, who knows?) to enquire what kind of "component library" I have used, and if that occurs I might well wrap AuthorBase up and start selling licenses. But they would have to convince themselves by virtue of seeing and using a live application or two. I would have a hard time pitching something like AuthorBase out of the blue. The products, and for this kind of framework they would have to be very real products (not some kind of Notepad clone), need to be out there first (if only for quality assurance purposes, let alone the fact that these represent very real, time-consuming projects that hopefully will deliver a lot of value to as many individuals and teams as possible)—no amount of marketing lingo will sell developers or program managers a prefabricated application design scaffolding; however, a couple of successful live showcases might well do the trick.

Takeaway: no productization plans for AuthorBase at all, no time investment into it other than what is required by my current product development; but I'm aware that such an opportunity might well present itself, and I will probably not let it pass if that happens.

[1] As an indication that this risk perception exists quite in the way I describe, consider the fact that while generalized application frameworks, which suggest their own, unknown and unproven design philosophy to developers (such as ) have a hard time gaining mainstream acceptance, there are other packages that prove extremely successful and serve the same purpose—to save time reusing attractive off-the-shelf design decisions (though mainly only as far as the GUI is concerned). The difference is that those are proven, widely distributed and thus standardized and consistent: witness the ubiquitous Microsoft -- . The risk element I talked about is simply taken care of here. If you want to sell your ready-made application design approach to developers,  it is that fear that you'll need to address and overcome.