The problem with DbM, as I understand it was less to do with the selection of bricks (by necessity of production it is always going to be limited in comparison with Extended Mode), but rather that the sheer cost of having to manually fulfil each order made any sort of profit margin razor thin. Ironically, the people like us were not overly interested in the premium attached to that custom process and were much more likely to use LDD to design something then obtain parts through the second hand markets.

Unless they could find a way to fully automate such custom products, which seems unlikely, any sort of DbM scheme is unlikely to offer tem suitable ROI. I hope they can find a way to make LDD a good revenue stream, as it is a fantastic tool, but I'm not holding my breath for it.

Update from 01/21/2016:

There is a new Statement of LEGO®, this time by Tanja Friberg (Senior Manager LEGO® Community Support).

"Dear Ambassadors, I hope this will help clarify a bit of the confusion and misunderstanding from our end Regarding LDD. TLG will remain committed to digital building going forward, in regards to LDD, This Means That We will continue to support the current functions on this page. We will not be doing automatic updates on element, HOWEVER elements will continue to be added from time to time. Unfortunately we can not Ensure That All elements are made available. I Can See That the message has spread Widely in the community since yesterday's statement and I Hope that you will assist us in spreading this message as well. Thank you."

With “use them,” I meant “use the file formats” = be able to read them, which, generally, you can do without problems (that’s called “interoperability”). For LDD’s bricks (.g), LDD2POVRay and Bluerender already do that.

Ah, I see where confusion is coming from. Let me explain.

Yes, LDD2POVRay and Bluerenderer are using data from LDD, but in order to do that, you must download and install LDD by yourself. This is key point here - you may use files which are legally installed on your computer, but you may not distribute files of someone else. So, you your program require LDD to be installed in order to use its library - that's OK. But distribute LDD's library (or anything derived from it) along with your program - not OK.

So, IMHO relying on LDD library is bad proposition - this data is internal to LDD and developers are not required to maintain backward compatibility even IF application is continued to be supported.

Ah, I see where confusion is coming from. Let me explain.[…]

Yes, my bad: I explicitly separated the distribution problem before but not in there.

So, IMHO relying on LDD library is bad proposition - this data is internal to LDD and developers are not required to maintain backward compatibility even IF application is continued to be supported.

Yes. “Relying” is wrong, “being inspired” is better, “being able to import/export” is best

(As a programmer (and MOCer), I tend to have the “fear of the blank page”: I prefer to start with something that exists and somewhat works rather than starting from scratch. And oftentimes, in the end, I realize that not much is left of what I started with and maybe it’d have been faster had I started from scratch )

Edited January 31, 20169 yr by SylvainLS