[GE users] Followup project

ron ron_chen_123 at yahoo.com
Fri Aug 20 14:01:30 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. ]

Thanks Andy, and this is really one of the few responses related to the future of the SGE open source project from an Oracle employee.

The reason why I started the "fork" is because we need to maintain the software running on clusters that do not have an Oracle support contract. They, as you mentioned, need a good DRM system. Also, the Rocks Cluster Distribution needs an open source version of Grid Engine. Even if Oracle gives away free SGE binraries, they won't accept it.

(I put fork in quotes because we will merge back with the project in the future if the Oracle-paid developers are going to use the open source model. As others have already mentioned, forking is not something we really want to see, but we also don't want to see an unmaintained version of Grid Engine neither!)

We will be spending the next few months in bug fixing mode before we start anything new, and Univa UD works with the Sun and Oracle developers to fix bugs, so it's not like no commercial entities are interested in fixing bugs in SGE.

Finally, I've seen finicial companies using the open source version of SGE without having a support contract. And they have a few clusters with close to 5000 cores in total, and SGE has been working for them almost perfectly for more than 5 years.


--- On Fri, 8/20/10, andy <andreas.schwierskott at oracle.com> wrote:
> Joe,
>  > 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?
> Regards,
> Andy
> ---
> 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
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275622
> To unsubscribe from this discussion, e-mail: [users-unsubscribe at gridengine.sunsource.net].


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

More information about the gridengine-users mailing list