One of the things that is challenging for me as a developer is staying on target with regard to ePublisher development when there are so many glittery web-technologies to play with. For example, I have have long yearned for a true AutoMap server which would allow for the Administration of ePublisher/AutmoMap configuration and execution over a web (http) connection. Recently I put together a Google Docs input adapter with the intention of demonstrating the capabilities of the ePublisher architecture. When it comes to inputs, I've got far more ideas than I have time to implement.
The real rubber meets the road, however, when it comes to the question of “what is commercially viable?” While it might be an interesting demo, it appears that there is not much interest in an ePublisher Google Docs adapter. Similarly, I have thought about and mostly implemented an Open Document input adapter, but again the primary concern about publishing such an adapter is that no one will want it or use it. Our larger ratio of FrameMaker users to Word and DITA users is pretty lopsided. But the fact remains that ePublisher is a viable tool for scenarios beyond technical publishing with FrameMaker input.
Before I was in development, I did consulting for users who wanted to do something custom with ePublisher that was not supported out of box. It was during this period that a lot of ideas regarding what's possible with the platform began to fall out. As we are not as much in the consulting business anymore, I feel that I've lost contact a little with some of the non-standard use cases. It is precisely these cases that interest me most. If you are someone who is using ePublisher in a way that doesn't fit the traditional model, I am very interested in your story.
I started a wave with Ben to try to get some feedback on this topic and he made the following comments:
Well, I think the focus problem boils down to there being so many ideas that are fun to work on, but getting any one of those “fun” ideas into a state you can ship takes most (all?) the fun out of the process.The other issue is trying to bound time spent on defects and creating value with new ideas. The problem is that one of these has known customer value (defects), while the other is unproven. The more we can “prove value” on the new ideas, the easier it becomes to focus on one thing and get success.
So how do we do that? How do we prove value? Generally, I prefer the “throw-it-at-the-wall-and-see-what-sticks” approach, hence, the Google Docs adapter. I admit that this might not be the fastest approach, but it's effective because it always deals with working code. Unfortunately, it takes a lot of code you have to throw away to get something to stick, but if you don't mind that, it seems to work OK.
Another approach is to try to eliminate or mitigate the amount of throw-away code you write by trying to guage whether an idea will be commercially viable before you ever write any code. Logically, this approach makes a lot of sense. However, in both cases it seems that effort is being applied to an idea which may or may not be of interest and there's dross in either result. It appears that in 2010, based on discussions I've had with Ben, we may begin trying the latter approach; building models or molds of an idea without actually coding it, to see if there is interest.
I should note that the purpose of the Projects section on the webworks wiki is to solicit ideas for features or uses, with the idea being that one of the developers would put time toward some of the items there. This remains a goal, but for the moment, one that I personally have not spent much time trying to develop.