When will ID Include Integrated Kindle .mobi Export?

Question

InDesign Mavens,
Can anyone shed any light regarding why Adobe has yet to include Kindle .mobi generation (export) as an integrated function in InDesign?
The release of InDesign CC further illuminates this problem...KDP's latest Kindle Plugin for Adobe InDesign (PERPETUAL BETA) v0.9.7.3 does not appear to support InDesign CC.
Really...by now...why is it necessary for Adobe to force InDesign users to rely on a third-party, perpetually BETA plugin for so many years in order to gain access to one of the largest (if not the largest) eBook marketplaces?
WHEN WILL ADOBE integrate Kindle .mobi generation into InDesign?
Do you want .mobi export integrated into InDesign? Please indicate your request in the comments below (hopefully someone from Adobe InDesign's Product Management group will get the message).

Answer 1

My apologies for the delayed response. Also, my apologies for the incorrect assumption about InCopy exporting to Word. I should have limited my response to things I have better knowledge of… but in my defense, I had just read this snippet in the InCopy manual and it seemed fairly clear, so I went with it:
Export InCopy documents
You can save all or part of an InCopy document in a different file format. In most cases, each component (for example, text frames and graphics) in an InCopy document is exported to a separate file. The exception is exporting an InCopy document to Adobe PDF, which copies all of the text and graphics in a document to a single PDF file.
Do one of the following:
       To export text, click in the text with the Type tool  .
       To export a graphic, click the graphic with the Position tool  .
Choose File > Export.
Specify a name and location for the exported content, and then select a format under Save As Type.
The XML format appears in the list only if XML tags have been added to the document. If you are exporting text and don’t see a listing for your word-processing application, you might need to export the text in a format that the application can import, such as Rich Text Format. If your word-processing application doesn’t support any of the InCopy export formats, use the Text Only (ASCII) format.
My assumption was, if InCopy allowed you to export to different file formats, and if it provided a listing of word processor programs, and it gave the option to export to RTF, then Word must be one of the options. Apparently I was wrong. That being said, the point I was making is still valid.
I am questioning the rationale behind Adobes decision to exclude support for the Amazon Kindle reader format. The reason stated here is, “Kindle uses a proprietary format that is not an open standard so why should Adobe spend the resources developing a solution to support it?” In response, I expressed doubt that this is the true reason because Adobe fails to take this position in other applications and I mistakenly provided an invalid example. So allow me to correct this mistake and reiterate that Adobe does not require that a technology or language be an “open standard” in order to incorporate support for the same.
These are examples of Adobe products supporting non-standard technologies (that I have personally verified from with the applications):
Acrobat Pro:      Export to Word and Excel          
Certainly these formats are not open standards
Photoshop:        Save as PXR format                      
Pixar originally created this proprietary format for use with proprietary Pixar Imaging Computers used in medical imaging applications and, of course, animation. Later it was adopted for use in Pixar’s Renderman and Marionette 3D animation programs. I didn’t research other image formats, but my guess is the majority are proprietary and not open standards.
Fireworks:          Export to Lotus Domino Designer           
Really? Is this what Adobe considers an open standard?
Dreamweaver:  Create files of type: ASP + Java Script, ASP + VB Script, ASP.NET C#, ASP.NET VB       
Obviously these are proprietary Microsoft technology solutions.
I think this demonstrates Adobe’s position on open standards fairly well, and as to the question of “Why” Adobe should support Kindle: for the same reason Adobe supports all the other, non-standard technologies. Because developers need it and Adobe is in the business of providing tools for developers. With regard to the characterization that Plane Wryter’s workflow is somehow “non-standard” is absolutely ridiculous. Yes, it might be true that the majority of Adobe’s ePub developers have no need for the Kindle tools. However, Plane Wryter and I (and every other independent developer and small ISV) cannot afford to limit our options and exclude potential clients based on (stupid) limitations imposed by our chosen development tools. We must remain flexible in order to survive. Adobe should recognize this and make an attempt to provide for our needs as well as the needs of their big enterprise customers.
Adobes position on this is a perfect example why I always look for tools created by smaller providers who have a vested interest in catering to the needs of the little guy. That’s why I chose tools from companies like Frame Technology Corp (creators of FrameMaker), eHelp/Blue Sky Software (creators of the RoboHelp product line) Aldus (providers of PageMaker, Freehand, and PhotoStyler), and Macromedia (creators of Flash, Shockwave, and Dreamweaver). I originally began to use these titles when they were competitors of Adobe, but they have since been acquired. It’s unfortunate that Adobe doesn’t see the value in continuing to provide small companies and individual developers with flexible tools. What other option does the little guy have except to look for alternatives from companies who still have an incentive to provide the tools we need?
In conclusion, I don’t buy the “not an Open Standard” excuse for excluding support for the Amazon formats. It’s an excuse of convenience and one that is not reflected by other Adobe products. The real reason Adobe isn’t providing development tools for Kindle is most likely tied to their Digital Editions reader application. I can see some Adobe Fat-Cat exec sitting at his desk on the 30th floor, with his feet up and chair leaned back, smoking a Gurkha (a very expensive cigar) of course, saying something like, “what kind of sense (puff) does it make (puff puff) to invest money and resources into (puff) a new ePub reader program, then (puuuufff) turn around and offer development tools (puff pu pu puff) for our competitors products? It doesn’t that’s what! Needles to say, we will NOT offer Kindle development tools (puff)”.
This sounds closer to the truth than that silly line about open standards. I don’t know about the rest of you guys, but I have a thing about being fed a line from a uber-mega-corp that’s acquired the vast majority of it’s product line through shrewd business practices. Do I honestly think they consider my needs as a developer? Naahh, not really. I’m going to follow Plane Wryter’s lead since Adobe leaves no other option.
One last word of caution to Plane Writer, I don’t like the way Steve Werner wished you luck with Vellum… (nothing personal Mr. Werner) but it almost sounded like “Good luck with Vellum, Adobe will be acquiring them real soon… “  Call me paranoid, but history speaks for itself, doesn’t it? If it’s a good product that’s competing with Adobe, then they will want it. (can you feel the walls closing in?)