[GE users] Followup project

andy andreas.schwierskott at oracle.com
Fri Aug 20 08:38:17 BST 2010

    [ The following text is in the "utf-8" character set. ]
    [ Your display is set for the "ISO-8859-10" character set.  ]
    [ Some characters may be displayed incorrectly. ]


 > Let me ask a (somewhat obvious) set of questions.
 > Is there any possibility that this project could be shut down due to
 > Oracle flexing legal muscle? That is, DanT looks like his group has
 > funding and a roadmap, and they might not take too kindly to an external
 > group building a relicensed version. Nor give their permission for
 > relicensure.

your question raises a fair concern and needs to be asked here. No one, 
neither contributing as an individual nor by representing a company 
wants to get involved in any legal troubles when kicking off a 
community-led fork of the Grid Engine project.

Though I'm now a Oracle employee and an old-timer in the Grid Engine 
engineering team since 16 years I can't speak for Oracle here. So I just 
can share my personal view: As I always understood the SISSL license 
gives the freedom to anyone to take the code and create a fork - even 
commercial versions seem to be allowed if the requirements of the SISSL 
are met. I agree a statement or clarification and explanation what can 
be done and what not were helpful.

And the legal question is not only about the code: I could not give an 
answer under which license the Issuezilla database and mailing list 
archives had been made available. That needs to be answered as well.

Undoubtedly the vast effort of all contributions with new feature 
development and bug fixing was contributed by Sun in the past 9 years 
since we went open source in June 2001. There were a few code 
contributions from our community (think about the array job 
interdependencies) and there was help with porting to new OS platforms 
(the most important certainly was the initial port to Mac OS X). In my 
view the greatest asset which had been created was the incredible 
adoption of Grid Engine and this tremendously active, helpful and 
positive mailing lists in the Grid Engine project. Also the many issues 
and bugs which had been reported by our community helped us to improve 
the quality of the Grid Engine code and helped others to get fixes 
before they ran into it as well. No doubt, that helped our paying 
customers as well.

All of you who are in the software business know what's the price tag of 
developing new features and fixing bugs. There are numbers which say a 
single bug on average costs more than $10k to fix. What I'm wondering is 
if the community will be able to sustain the code quality of the current 
feature set - and what's about new development or complete new modules 
which address new needs, like the Service Domain Manager? This thread 
originally has started with a memory reporting regression on Linux. That 
bug was easy to fix. Others we fixed in 6.2u6 (see here 
http://gridengine.sunsource.net/project/gridengine/62patches.txt) took 
even us many, many person weeks to analyze and solve them, not talking 
about the QA team and lab and the continuous investment in the testsuite 
to ensure and improve the quality of the released code on all of the 
supported platforms.

There's certainly quite some risk for anyone who is responsible for 
running clusters where every hour hundreds, thousands or tens of 
thousands CPU hours are waiting to kept busy and keep the company behind 
running. So is the assumed zero price tag worth the money you will lose 
if the DRM system of your choice does not work? Our customers are giving 
us figures which say that hardware, electricity, cooling, 
administration, OS licenses, DRM system licenses only make up one third 
of their costs. The remaining money goes into the licenses of the 
software which runs in the grid. Not talking about the labor costs for 
the engineers using the Grid. So can the license and support costs of a 
DRM system have any cost saving potential when you compare it with the 
value it adds to the bulk of hardware in a data center?

Snr Software Development Manager, Grid Engine
ORACLE Deutschland B.V. & Co. KG
Dr.-Leo-Ritter-Str. 7
D-93049 Regensburg
ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603
Komplementärin: ORACLE Deutschland Verwaltung B.V.
Rijnzathe 6, 3454PV De Meern, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven


To unsubscribe from this discussion, e-mail: [users-unsubscribe at gridengine.sunsource.net].

More information about the gridengine-users mailing list