JAXenter: Andreas Korzinowski hatte zu dem einleitenden Interview mit Aljoscha Rittner folgenden Kommentar abgegeben:

Ich hoffe, dass die Sun-Übernahme nicht dazu führt, dass die Weiterentwicklung von Netbeans beeinträchtigt wird, sondern man auf der Seite von Oracle erkennt, welches Potenzial in diesem Framework vorhanden ist.

Aljoscha Rittner: NetBeans IDE und die NetBeans Platform werden auch unter Oracle weiterentwickelt. Der Middleware Chief Architect Ted Farell sieht die NetBeans IDE als strategisches Java-Entwicklungstool für alle von Sun bisher entwickelten Java-Stacks: JavaME, JavaSE, JavaEE und auch JavaFX. Zu JavaEE wird auch GlassFish beibehalten. Weiterhin bleibt die NetBeans IDE die Entwicklungsumgebung für dynamisch getypte VM-Sprachen (Scala, Groovy usw.) und Skriptsprachen (z.B. PHP).

Die Weiterentwicklung von NetBeans erfolgt nun unter der Regie von Oracle. Große Veränderungen bei den Entwicklungsteams ist nicht zu erwarten. Allerdings möchte Oracle eine stärkere Einbindung der Community erreichen.

JAXenter: Nils Grochtinger stellte folgende Frage:

Wie abhängig ist NetBeans eigentlich von Sun (bzw. jetzt Oracle)? Ist es nicht denkbar, NetBeans in eine "unabhängige" (vendor neutral) Institution à la Eclipse Foundation zu überführen und damit das Schicksal einer so wertvollen IDE von den wirtschaftlichen Unwägsamkeiten zu entkoppeln?

Aljoscha Rittner: Die Abhängigkeit NetBeans von dem "Besitzer", ehemals Sun – nun Oracle, führte schon seit jeher zu kontrovers geführten Debatten. Es kann nicht mal gesagt werden, ob eine Überführung in eine Foundation NetBeans tatsächlich voranbringen würde. Wenn man nur den Blick in die Vergangenheit richtet, hatte NetBeans keine Schwierigkeiten, im Wettbewerb zu bestehen. Ansonsten wären wir heute mit NetBeans nicht an dieser erfolgreichen Position.

Beide Formen der "Verwaltung", Foundation oder Besitz, haben ihre Vor- und Nachteile. Bei einer Foundation besteht die Gefahr, dass zu viele Köche den Brei verderben. Im Gegensatz dazu bedeutet Oracle als einzige führende Kraft darauf hoffen zu müssen, dass der eine Koch ein 5-Sterne Koch sein wird.

Oracle möchte aber unbedingt eine stärkere Einbindung der Community. Um erfolgreich mit diesem Konzept zu sein, ist sowieso damit zu rechnen, dass es Bestrebungen gibt, die eng gekoppelten Entwicklungsstrukturen aufzubrechen. Auch wir Mitglieder des NetBeans Dream Team sind sehr dafür, dass in Zukunft nicht alles komplett in einer Hand liegt. Man schaut sich nur das Dilemma mit kenai.com an. Viele NetBeans Contributor Projekte müssen nun umziehen, weil Oracle den Dienst einstellen will. Solche "Einzelentscheidungen" wollen wir natürlich in Zukunft etwas abgefedert haben.

Letztendlich erlauben die Lizenzen, unter denen die NetBeans-Entwicklung läuft, ohne Probleme jederzeit eine Abkoppelung, ohne von einer zentralen Entscheidung abhängig zu sein. Im Moment sehe ich aber keine Notwendigkeit für einen solchen Fork.

JAXenter: Thomas kommentierte:

Was hat NetBeans für MDSD/MDA Architekten bzw. Softwareentwickler, die modellgetrieben entwicklen, zu bieten? Eclipse hat das sehr ausgereifte EMF, welches für mich inzwischen *die* Killerapplikation darstellt.

Aljoscha Rittner: Mit der Akquisition von Sun durch Oracle und der Ausrichtung der Tools JDeveloper und NetBeans sehe ich im Moment keine hohe Motivation, MDSD/MDA in NetBeans auszubauen. JDeveloper hat entsprechende Tools, und diese werden höchstwahrscheinlich nicht nach NetBeans migriert. Das bedeutet aber keine generelle Absage, weil in anderen Bereichen tatsächlich Überlegungen existieren, Features nach NetBeans zu bringen (z.B. ADF Plug-ins für die JavaEE/JSF Module in NetBeans).

Vielleicht gibt es aber in Zukunft andere Möglichkeiten, dass NetBeans von dem hohen Potenzial durch MDSD/MDA profitieren kann. Mit einem hohen Tempo wird die OSGi-Integration in das Modul- und Plug-in-System vorangetrieben. Es ist also nicht mehr unwahrscheinlich, dass es in Zukunft einfacher werden wird, für NetBeans und Eclipse gemeinsam Plug-ins zu programmieren, ohne auf jeder Plattform von vorne anfangen zu müssen.