[Aust-NZ] Re: [GeoNetwork-devel] Geonetwork UI Design

Wed May 28 07:30:06 EDT 2008

Clive,
Unfortunately, the scope of our project only includes improvements to 
the Geonetwork UI, and hence our design will only focus on our new UI 
code, not the entire Geonetwork codebase.

However, you highlight one of the challenges faced by Open Source projects:
Long term, projects benefit by addressing the core infrastructure of the 
project because it makes software developers more effective. Things like:
* Writing design and user documentation
* Developing automated build and test systems
* Refactoring code to be easier to maintain

Good proprietary software development houses will address these issues 
because they have a 1:1 return on investment. Because they own the 
source code, they are the only people who can contribute to it, and also 
the only beneficiaries.

The Open Source business model is more difficult. Sponsors often only 
provide funds to add an extra feature, but do not contribute toward the 
general health of the project.

The very valuable Open Source sponsors provide the infrastructure 
support. The value for the sponsor is that their investment will ensure 
other developers can contribute to the project more efficiently and the 
sponsor will reap the fruits of their investment - in the medium to long 
term.

In Geonetwork's case, it seems likely that CSIRO may be in a position to 
provide that core sponsorship in the near future.

CliveB wrote:
> Cameron, Simon and others,
>
> It's good to hear that some work is being started on establishing the
> existing design of Geonetwork.  I have started some of this myself looking
> into the GN Java side class/method relationships and the InterMap
> Javascript/XSL function relationships/calls.  Basically what I've produced
> is a couple of (big) matrices with the same set of artifacts as column and
> row headings, with the cells as intersections indicating the type of
> connection between any two classes, methods, functions or combinations
> thereof.
>
> Part of the reason for doing so lies in the fact that whilst there are
> diagrams available that look something like what you've attached to your one
> of your emails, there is no overarching document showing any real detail
> about the sorts of connections across the boundaries that you've identified
> or internally to any of the 'blocks' shown on your diagram.
>
> BTW, in the main, the code that I've examined is not too shabby and doesn't
> seem to contain too many inconsistencies.  However, amonsgt the Javascript
> there are several superfluous files that are either not used, or as in one
> case, only two functions are used out of what seems to be a completely
> unrelated application to do with online purchasing using credit cards. 
> Other potential inconsistencies crop up when JS functions that probably
> should be within in the InterMap JS files appear in the XSL code.  There is
> also a little bit of pure 'convenience' usage within the XSL stuff of JS
> functions within InetrMap.  At this point in time, there's not too many
> inconsistencies.  My concern is that they might grow and make the code even
> harder to decipher.
>
> This takes me to commenting on the fact that the Geonetwork system
> (including Intermap) is largely undocumented/uncommented code.  If one takes
> the system as is with no need to enhance/change the code, then there's no
> real problems (at least from the user perspective) other than reporting bugs
> and waiting for them to be fixed.  However, if (like we are required to do
> at Software Improvements) one has to provide extensive changes touching on
> many of the different elements of geonetwork, then it is very time consuming
> getting to a position in order to be able to define a strategy to design and
> implement something that is going to both fulfill the customer requirements
> and at the same time be relatively independent of future changes to
> geonetwork.
>
> I'm seeing exactly the same set of issues associated with a number of other
> opensource systems where all the knowledge, design decisions and
> (apparently) the requirements are represented in code and little else. - and
> these systems are supposed to be reusable!!   All of these systems have
> grown to a point where the most effective path is to capture the designs and
> document them together with requirements, associated tests etc. 
> Unfortunately, there's a cost, and no-one seems willing to pay despite the
> fact that the cost of inefficiency will continue to grow with time and
> ultimately threaten the very survival of the systems.  It seems to me that
> with what I've been doing together with what the developers (Richard and
> Ming) have had to do, it's time for the Geonetwork software to undergo some
> some strategic thinking if it is to be of continued benefit to it's current
> and future (hopefully larger) community.
>
> So, an appropriate, low cost, strategy at this time in the development of
> geonetwork would be to have a community wide investment in providing
> adequate commentary in the code.  After that, it would be appropriate to
> re-engineer and document the design (already started).  Then the
> requirements (preferably in the form of a comprehensive model) that have led
> to the current version together with how they relate to the design, should
> be followed up.  Whatever is done in terms of documentary improvement has to
> be kept up to date with (continuing) change - in short, proper change
> control.  Doing this would potentially grow the user/contributor base
> because the system would be easier and quicker to comprehend, and (at least)
> obviate the wastage of time inevitable when having to essentially undergo
> the (typically undocumented and partial) re-engineering process, repeatedly. 
> Doing all this would also provide a better platform for the gate-keepers of
> geonetwork to assess impacts of change and to monitor who is contributing to
> what part of the system and doing so independently - again avoiding wasted
> time.  Finally, with this work an appropriate test suite could also be
> developed and updated with changes.  Any contributor would have to
> demonstrate clearly what requirements they are treating, how they
> affect/impact the design/code and demonstrate validity through system and
> acceptance which are added to the current suite.  Obviously, a significant
> load would be taken off the gatekeepers because the responsibility of
> ensuring that updates are accepted is largely thrown back on to
> contributors.
>
> I'll be following up with more suggestions in the hope that the community
> might eventually decide that at least some of what I'm suggesting is
> sensible and will allow greater product stability, quality and productivity
> for all contributors and users.
>
> Clive.
>
>   
>
> Cameron Shorter wrote:
>   
>> We had a very productive face to face meeting last week to discuss the
>> design of an enhanced Geonetwork metadata record collection interface
>> last week.
>>
>> Present:
>> Simon Pigot (CSIRO and Geonetwork developer),
>> Evert Bleys (BRS, representing the customer, and expert on ANZLIC
>> profile),
>> Roald de Wit (LISAsoft, developer)
>> Simon Green (LISAsoft, developer)
>> Cameron Shorter (LISAsoft, project manager/tech consultant)
>>
>> Simon and Roald have started writing up the design, diagram is attached,
>> and we would like to determine a good place to put the rest of the
>> design. We can set up a wiki on the LISAsoft website, but I suspect it
>> would be better to use a Geonetwork wiki? What do you think?
>>
>> Next, could we please get accounts for Roald, Simon and myself to the
>> geonetwork svn sandbox.
>> My preferred username is camerons.
>> Roald, Simon, could you please suggest your username.
>>
>> --
>> Cameron Shorter
>> Geospatial Systems Architect
>> Tel: +61 (0)2 8570 5050
>> Mob: +61 (0)419 142 254
>>
>> Think Globally, Fix Locally
>> Commercial Support for Geospatial Open Source Solutions
>> http://www.lisasoft.com/LISAsoft/SupportedProducts.html
>>
>>
>>
>>  
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> GeoNetwork-devel mailing list
>> GeoNetwork-devel at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
>> GeoNetwork OpenSource is maintained at
>> http://sourceforge.net/projects/geonetwork
>>
>>     
>
>   

-- 
Cameron Shorter
Geospatial Systems Architect
Tel: +61 (0)2 8570 5050
Mob: +61 (0)419 142 254

Think Globally, Fix Locally
Commercial Support for Geospatial Open Source Solutions
http://www.lisasoft.com/LISAsoft/SupportedProducts.html