Entwicklungsprozess -> ScriptBibliotheken auslagern

[animate]

Ich hab eine methodische Frage:
Wir (meine Firma) entwickeln eine NotesDB und verkaufen sie. Sie basiert auf einem Framework (LotusScript-Klasse in ScriptBibliotheken), in dem viel Gehirnschmalz steckt, deshalb möchten wir es vor den Augen Fremder verbergen. Im Moment tun wir das, indem wir die Gestaltung der DB verbergen.
Viel schöner wäre es aber (IMHO), wenn wir die Bibliotheken in ASCII-Dateien auslagern würden und per %Include in der DB verwenden würden - der Benutzer könnte Masken, Views, etc. dazubauen/verändern.
Um bei dieser Methode aus einer EntwicklungsDB eine DB für Kunden zu erstellen, müsste man, idealerweise automatisiert, eine Kopie des Entwicklungsstandes machen, die Scriptbibliotheken der Kopie exportieren (in ASCII-Dateien), die ScriptBibliotheken selbst leeren und mit einem enstprechenden %Include-Statement besetzen und dann kompilieren.

Kann mir hierzu evtl schon jemand beipflichten bzw kann mich jemand von euch verbessern, falls ich falsch liege?

Alles funktioniert, wenn ichs per Hand mache, automatisch schaff ichs bis zum Export der Bibliotheken, ich kann aber ihren Inhalt nicht verändern. D. h,. ich kann den Inhalt zwar verändern, das resultiert aber in Generic LSE Failure (oder so ähnlich).
Hat hierzu vielleicht schon jemand Erfahrung gesammelt?
Ich würde mich über Antworten, Kommentare, BestPractices, etc. freuen...

[Semeaphoros]

Erfahrung gesammelt noch nicht, aber ich verfolge eine ähnliche Strategie

[eknori]

ich kenne das Problem

der einzige weg ist, alle allgemeinen Libs per include einzubinden, ihr solltet aber den Code so flexible gestalten, daß ihr s.g. UserExits einbaut. Bis zu dem Teil ist der Code verborgen; ihr müsst dann aber auch die Schnittstelle zu den UserExits oder gar einer Api offenlegen

[Semeaphoros]

Richtig. Nur, wenn ichs nicht falsch verstehe, fragt er nach einem automatisierten Prozess, um aus den Entwicklungs-DBs automatisch Produktions-DBs zu erstellen

[eknori]

geht alles.. Frage, Aufwand ??

[Axel_Janssen]

... vielleicht ist tatsächlich xml hier ein vielversprechender Ansatz. Man kann das xml ja irgendwie verschlüsseln. Aber dann eine GUI basteln, die das editieren von bestimmten Gestaltungsmerkmalen ermöglicht Ui da müssen wir aber noch eine Menge Stagnations-Jahre erleben, bis die Löhne soweit im Keller sind, dass sich das rechnet (was ich nicht hoffe und glaube).

... aus meiner Erfahrung verlangen auch viele Kunden explizitst eine offene Gestaltung. Das sieht vermutlich im Mittelstand ein bischen anders aus.

Die Frage taucht by the way auch immer wieder in de.comp.lang.java auf. Die meisten der dortigen Gurus vertreten die Auffassung, dass man zwar nicht alles openSource stellen muß aber auch keine Verrenkungen machen sollte, da das Erfahrungsgemäß nichts lohnt.

Du mußt natürlich aufpassen, wem du den source code gibst. Bei der alten Firma meldeten sich auch öfters mal Schein-Firmen, die sich dann als Konkurrenten rausstellten.

In keinem Fall sollte man obskur programmieren, nur um den Source code schwerer crackbar zu machen.

Meine Erfahrung ist, dass man sich nicht auf Produkte verlassen kann, um finanziell zu überleben. Das Geld verdient man mit schnöden Consulting/Training. In meiner alten Firma ist man einen anderen Weg gegangen. Die haben zwar wirklich gute Notes-Produkte, sind international aufgestellt, etc. Trotzdem wurden dieses Jahr 3 Geschäftsstellen in Deutschland dichtgemacht und der im Internet veröffentlichte Geschäftsbericht der letzten 9 Monate sieht genauso bedrohlich aus, wie die genauso öffentlich im Internet ausgestellten Geschäftsberichte der letzten Jahre. Die Stimmung war dann am Ende entsprechend.

Also: Es geht nicht nur darum ein dolles Produkt zu haben, sondern man muß um jeden Euro kämpfen. Also: Support, freundliches, positives Auftreten. Und immer schaun wo es einen Markt gibt.

Das Problem ist natürlich: Je besser man programmiert, desto übersichtlicher ist es und umso leichter ist es für Leute sich da was rauszuziehen. Auf der anderen Seite müssen diese Leute eine gehörige Portion an Erfahrung haben. Das verstehen von fremden code, über den man auch keinen fragen kann, gehört ja auch nicht grade zu den interessantesten todos.

Die andere Seite wäre Kostensenkung durch Prozeßmanagement (großes Wort). Ich meine: Wenn man ein eingespieltes Team hat, dass sich gegenseitig vertraut und wirklich zusammenarbeitet, kann man eine Menge Geld sparen. V.a. wenn sich das Team wirklich kostenbewußt ist. Kostenbewußtsein fällt in der Realität IMHO allen schwer.

und das eigentliche Problem sind sowieso Kunden (bin bis Ende Dez. sicher 100% ausgebucht und danach zeichnen sich angeblich auch schon neue Sachen ab).

wünsche euch viel Glück

Axel