Printing Reports in uDIG

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Printing Reports in uDIG

Craig Taverner-2
Hi,

I have two related questions regarding printing in uDIG:

We are investigating how to print reports from AWE, an application based on uDIG 1.1.1. The current material on the uDIG wiki seems to be quite old (I saw last modified dates in 2005). Has the uDIG printing infrastructure changed much from what the wiki says compared to uDIG 1.1.1? (things like PageEditor, Template, BoxPrinter and Palette View). Some specific questions: how to print tables and charts? Support for headers and footers and references?

(perhaps I should also ask, has printing changed much for uDIG 1.2 also - obviously at some point we will finally move to that branch :-)

And the second question:

We have developed a JRuby based DSL for specifying report content, and prototyped this in plain SWT, and today allows us to specify tables and charts based on data in a database. However, we would like to use the DSL to drive the uDIG printable reports (PageEditor), supporting maps, text, tables and chart. What makes sense to us would be to have style and content separation. I guess the style would be controlled by things like the Template, while the content is specified in the DSL. This will allow, among other things, automated report generation outside the desktop environment. Does this sound like a feasible idea?

Regards, Craig

_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel
Reply | Threaded
Open this post in threaded view
|

Re: Printing Reports in uDIG

Andrea Antonello
Hi Craig,
sorry for beeing late, I guess I was the last one working on printing lately.

To be honest I only worked a bit with the extention points to add more
stuff on the map and fixed mainly scale and paper issues, that were
inexisting. Then I found lots of problems in the drawing of the
graphics like legends and so, since they do not scale properly from
the moment that udig started to think in paper and scale instead of
pixels. At that point my time for this finished and some things are
still missing.

I am afraid that doesn't answer any of your questions, but at least it
makes you feel somebody cares :)
It would be great to have you guys on trunk.

Andrea

> I have two related questions regarding printing in uDIG:
>
> We are investigating how to print reports from AWE, an application based on
> uDIG 1.1.1. The current material on the uDIG wiki seems to be quite old (I
> saw last modified dates in 2005). Has the uDIG printing infrastructure
> changed much from what the wiki says compared to uDIG 1.1.1? (things like
> PageEditor, Template, BoxPrinter and Palette View). Some specific questions:
> how to print tables and charts? Support for headers and footers and
> references?
>
> (perhaps I should also ask, has printing changed much for uDIG 1.2 also -
> obviously at some point we will finally move to that branch :-)
>
> And the second question:
>
> We have developed a JRuby based DSL for specifying report content, and
> prototyped this in plain SWT, and today allows us to specify tables and
> charts based on data in a database. However, we would like to use the DSL to
> drive the uDIG printable reports (PageEditor), supporting maps, text, tables
> and chart. What makes sense to us would be to have style and content
> separation. I guess the style would be controlled by things like the
> Template, while the content is specified in the DSL. This will allow, among
> other things, automated report generation outside the desktop environment.
> Does this sound like a feasible idea?
>
> Regards, Craig
>
> _______________________________________________
> User-friendly Desktop Internet GIS (uDig)
> http://udig.refractions.net
> http://lists.refractions.net/mailman/listinfo/udig-devel
>
>
_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel
Reply | Threaded
Open this post in threaded view
|

Re: Printing Reports in uDIG

Jody Garnett-2
In reply to this post by Craig Taverner-2
Hi Craig:

> We are investigating how to print reports from AWE, an application based on
> uDIG 1.1.1. The current material on the uDIG wiki seems to be quite old (I
> saw last modified dates in 2005). Has the uDIG printing infrastructure
> changed much from what the wiki says compared to uDIG 1.1.1? (things like
> PageEditor, Template, BoxPrinter and Palette View). Some specific questions:
> how to print tables and charts? Support for headers and footers and
> references?

The core infrastructure has remained the same; with some extensions to
make map graphics aware of DPI (so we can print scalebars on high dpi
devices and so on). Many of these changes were to the classes used for
printing; not changing the core Box Page data model.

The printing system has received some updates since 2005 :-)
- Emily did a lot of working putting together mapgraphics for tables
and borders and extending support for multiple pages. This work was
unable to be contributed back but we can ask for details.
- Andrea has gone through some of the scale dependent QA issues as he
has already indicated.

We have also settled on a couple of best practices; in terms of
placing extra information on the map blackboard for the various
mapgraphics (like say a "details" table) to print out. This allows an
operation to set up a map as a copy of the current display; fill in
the map blackboard and pass the result over to ApplicationGIS for
rendering.

There is one other track that has seen success. We also have a number
of teams that have used BIRT in conjunction with uDig map rendering
capabilities; one of them did donate the code while I was at
Refractions but I never got a chance to look at it.

> (perhaps I should also ask, has printing changed much for uDIG 1.2 also -
> obviously at some point we will finally move to that branch :-)

With respect to 1.2 vs 1.1.1 differences your team is welcome to back
port and issue another release of 1.1.x.

> And the second question:
>
> We have developed a JRuby based DSL for specifying report content, and
> prototyped this in plain SWT, and today allows us to specify tables and
> charts based on data in a database. However, we would like to use the DSL to
> drive the uDIG printable reports (PageEditor), supporting maps, text, tables
> and chart. What makes sense to us would be to have style and content
> separation. I guess the style would be controlled by things like the
> Template, while the content is specified in the DSL. This will allow, among
> other things, automated report generation outside the desktop environment.
> Does this sound like a feasible idea?

That does; and it sounds superior to the best practice outlined
earlier. The Page / Box should be the content model; and BoxPrinter
(or any other printer you need) should be able to provide the
rendering.  We also have the concept a "template" that can be used to
create a Page given a couple of bits of information (page size, a IMap
to start from etc...).

Andrea has started using a charting library; I have managed to use
BIRT charting before. So this may be a case where community discussion
sets the direction.

Jody
_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel
Reply | Threaded
Open this post in threaded view
|

Re: Printing Reports in uDIG

Craig Taverner-2
Thanks Andrea and Jody for the responses.

It sounds like most of the progress since 2005 has happened in trunk (1.2), and some of it even outside trunk (Emily's work). So we need to see how best to make use of this. I've asked Elena to review the code differences between uDig 1.1 and trunk, and we would like to get access to Emily's code also, so we can review that too. We would need to either back-port both the trunk and Emily's work to uDIG 1.1, or plan an earlier move to uDIG 1.2. We are busy trying to complete a customer delivery for the end of February, and so we don't want to move to 1.2 until March at the earliest.

The printing system has received some updates since 2005 :-)
- Emily did a lot of working putting together mapgraphics for tables
and borders and extending support for multiple pages. This work was
unable to be contributed back but we can ask for details.

Can we get access to this code? Why was it not contributed back? We have done a prototype already where we have charts and tables inside the uDIG printable page, but it would be best to do this based on Emily's work, if possible.
 
- Andrea has gone through some of the scale dependent QA issues as he
has already indicated.

I'm assuming this is on trunk, and not in uDIG-1.1? Elena is busy reviewing the code differences, so hopefully we will figure that out ourselves, but it would be good to hear from the real experts. Andrea dropped a strong hint when he said it would be good to have us on trunk ;-)

There is one other track that has seen success. We also have a number
of teams that have used BIRT in conjunction with uDig map rendering
capabilities; one of them did donate the code while I was at
Refractions but I never got a chance to look at it.

We reviewed BIRT last year but did not go ahead with it because it was actually a very complex system and we felt that would make it harder for us to use our report scripting ideas. But the code might still be worth reviewing.

With respect to 1.2 vs 1.1.1 differences your team is welcome to back
port and issue another release of 1.1.x.

Another strong hint that all new printing work has been done to udig-1.2 ;-)
If we do decide to use the 1.2 printing in AWE today, we will try make a 1.1.x release of uDIG for that. I know we talked about doing that before when we included a critical linux bug-fix last year, but I backed out of actually making a udig release, as I felt slightly intimidated, sorry. Perhaps I'll get my act into gear this time :-)

> separation. I guess the style would be controlled by things like the
> Template, while the content is specified in the DSL. This will allow, among
> other things, automated report generation outside the desktop environment.
> Does this sound like a feasible idea?

That does; and it sounds superior to the best practice outlined
earlier. The Page / Box should be the content model; and BoxPrinter
(or any other printer you need) should be able to provide the
rendering.  We also have the concept a "template" that can be used to
create a Page given a couple of bits of information (page size, a IMap
to start from etc...).

It is beginning to sound more like our DSL would actually generate the template itself. Since the DSL specifies the complete content, like number of maps, charts and tables and their ordering in the report. The only thing the DSL does not specify is the style (fonts, colors, etc.). When comparing with HTML/CSS, our DSL will generate the complete HTML and contained objects (maps, tables, charts, images), but not the CSS.

Andrea has started using a charting library; I have managed to use
BIRT charting before. So this may be a case where community discussion
sets the direction.

Great. It would be good to know how Andreas charts, your BIRT work and our JFreeChart work overlap, and we can try to converge a little.

Regards, Craig


_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel
Reply | Threaded
Open this post in threaded view
|

Re: Printing Reports in uDIG

Jody Garnett-2
Can we get access to this code? Why was it not contributed back? We have done a prototype already where we have charts and tables inside the uDIG printable page, but it would be best to do this based on Emily's work, if possible.

In general when a consulting company, like Refractions or LISAsoft, does work for a customer the work is not contributed back - unless the customer sees the value and is willing to pay for the extra overhead involved.

If you do find yourself working for a customer the ideas is roughly to trade reduced maintenance cost for the upfront cost checking with the community (perhaps a design to be reviewed from the PSC?).

There is one other track that has seen success. We also have a number
of teams that have used BIRT in conjunction with uDig map rendering
capabilities; one of them did donate the code while I was at
Refractions but I never got a chance to look at it.

We reviewed BIRT last year but did not go ahead with it because it was actually a very complex system and we felt that would make it harder for us to use our report scripting ideas. But the code might still be worth reviewing.

The charting part of BIRT is actually independent and nicely done.

Another strong hint that all new printing work has been done to udig-1.2 ;-)

No so much as a hint; more that I cannot remember the work that was done on 1.1.x since I was not part of it.

That does; and it sounds superior to the best practice outlined
earlier. The Page / Box should be the content model; and BoxPrinter
(or any other printer you need) should be able to provide the
rendering.  We also have the concept a "template" that can be used to
create a Page given a couple of bits of information (page size, a IMap
to start from etc...).

It is beginning to sound more like our DSL would actually generate the template itself. Since the DSL specifies the complete content, like number of maps, charts and tables and their ordering in the report. The only thing the DSL does not specify is the style (fonts, colors, etc.). When comparing with HTML/CSS, our DSL will generate the complete HTML and contained objects (maps, tables, charts, images), but not the CSS.

Andrea has started using a charting library; I have managed to use
BIRT charting before. So this may be a case where community discussion
sets the direction.

Great. It would be good to know how Andreas charts, your BIRT work and our JFreeChart work overlap, and we can try to converge a little.

Andrea was using JFreeChart I think; also JFreeCharts can be used *inside* the rendering process to place little pie charts and stuff directly on your map ... 

Jody

_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel
Reply | Threaded
Open this post in threaded view
|

Re: Printing Reports in uDIG

Riccardo Rigon

On Jan 30, 2010, at 12:29 AM, Jody Garnett wrote:

Can we get access to this code? Why was it not contributed back? We have done a prototype already where we have charts and tables inside the uDIG printable page, but it would be best to do this based on Emily's work, if possible.

In general when a consulting company, like Refractions or LISAsoft, does work for a customer the work is not contributed back - unless the customer sees the value and is willing to pay for the extra overhead involved.

If you do find yourself working for a customer the ideas is roughly to trade reduced maintenance cost for the upfront cost checking with the community (perhaps a design to be reviewed from the PSC?).


i accept it (it is allowed), but I think it is a narrow perspective. The success of a software depends on how good it is. And the success of a company that (maybe among other things) develops that software is tied to the diffusion of the software (besides the ability of its management).  No software diffusion, no business. I think there is a trade-off between different needs, and a behavior that maximize the company fitness which is not the complete closure. 

However, this is just my humble opinion.  For the community, I think it would be interesting to know an estimation of these  extra-costs, which maybe could be conveniently paid by other.

Long life to udig.

riccardo



There is one other track that has seen success. We also have a number
of teams that have used BIRT in conjunction with uDig map rendering
capabilities; one of them did donate the code while I was at
Refractions but I never got a chance to look at it.

We reviewed BIRT last year but did not go ahead with it because it was actually a very complex system and we felt that would make it harder for us to use our report scripting ideas. But the code might still be worth reviewing.

The charting part of BIRT is actually independent and nicely done.

Another strong hint that all new printing work has been done to udig-1.2 ;-)

No so much as a hint; more that I cannot remember the work that was done on 1.1.x since I was not part of it.

That does; and it sounds superior to the best practice outlined
earlier. The Page / Box should be the content model; and BoxPrinter
(or any other printer you need) should be able to provide the
rendering.  We also have the concept a "template" that can be used to
create a Page given a couple of bits of information (page size, a IMap
to start from etc...).

It is beginning to sound more like our DSL would actually generate the template itself. Since the DSL specifies the complete content, like number of maps, charts and tables and their ordering in the report. The only thing the DSL does not specify is the style (fonts, colors, etc.). When comparing with HTML/CSS, our DSL will generate the complete HTML and contained objects (maps, tables, charts, images), but not the CSS.

Andrea has started using a charting library; I have managed to use
BIRT charting before. So this may be a case where community discussion
sets the direction.

Great. It would be good to know how Andreas charts, your BIRT work and our JFreeChart work overlap, and we can try to converge a little.

Andrea was using JFreeChart I think; also JFreeCharts can be used *inside* the rendering process to place little pie charts and stuff directly on your map ... 

Jody
_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel

________________________________________________________________        
Universita` di Trento         Dipartimento di Ingegneria Civile  e  Ambientale/CUDAM
Via Mesiano, 77, 38050  Trento      (ITALIA)                        
E-mail[hidden email]  
Ph: +390461882614-10    Fax:+390461882672
Publications according to ISI: http://www.researcherid.com/rid/B-5395-2008
JGrass (Open Source GIS): http://www.jgrass.org/
GEOtop (Open Source distributed hydrological model):  http://www.geotop.org/
_______________________________________________________________                                                      





_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel
Reply | Threaded
Open this post in threaded view
|

Re: Printing Reports in uDIG

aaime
Riccardo Rigon ha scritto:

>> If you do find yourself working for a customer the ideas is roughly to
>> trade reduced maintenance cost for the upfront cost checking with the
>> community (perhaps a design to be reviewed from the PSC?).
>
>
> i accept it (it is allowed), but I think it is a narrow perspective. The
> success of a software depends on how good it is. And the success of a
> company that (maybe among other things) develops that software is tied
> to the diffusion of the software (besides the ability of its
> management).  No software diffusion, no business. I think there is a
> trade-off between different needs, and a behavior that maximize the
> company fitness which is not the complete closure.

In an economic climate where companies try to just stay afloat the
long term perspective is irrelevant. You don't care about what would
happen in 3 years time if you don't know whether you'll still be
around in 6 months to 1 year.
If you ever worked in a software company you should know the number
one cost (usually the only significant one) is personnel, the moment
you hit a reduction in requests you start firing people, and everyone
remaining will do his best to show the company she's the last one
to fire. Talking about how open source will help in the long run
in such climate will get you fired sooner rather than later.

> However, this is just my humble opinion.  For the community, I think it
> would be interesting to know an estimation of these  extra-costs, which
> maybe could be conveniently paid by other.

Depends. For small projects (5 days) it can be between 20-30% and
100%, for longer ones something smaller, like 20-30%.
It also boils down to how much you're respected in the community, how
good is the contribution you're providing in terms of code quality,
docs and testing. For some this can become an insurmountable roadblock.

Interacting with the community will also significantly slow you down
as you have deadlines, but everyones else is answering your mail
and posing concerns you have to answer to in their spare time.
A discussion that could be settled face to face in a couple of
hours can span two weeks. This is to not say you have two weeks
of overhead, but you have two weeks of delay and you'll have to
fill them with something else

There is also the problem of maintainance. If you just develop something
and plan to make it become core/supported intto a project, but you don't
offer long term maintenance you'll have to be lucky that someone else
is interesting enough and has time enough to care for your fantastic
contribution. Just offloading a contribution for a new
functionality/module to a developer group
that's already very busy won't do much good. However, that's what
consulting companies often hope/try to do.


Cheers
Andrea


--
Andrea Aime
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel
Reply | Threaded
Open this post in threaded view
|

Re: Printing Reports in uDIG

Craig Taverner-2
Wow! This discussion has gone way off from the original printing capabilities discussion. However, the discussion is very relevant to my work too, so I'll throw in my two cents.

I think when considering contributing code back, everything boils down to the business case. If it is important to the business case, you contribute back. But Andrea's point is very relevant too, since he says it is really the short term business case that counts. In our case contributing back makes sense for our medium and longer term business case, but in the short term it matters very little.

This has resulted in us contributing very little back (yet), but remaining fully interested in contributing back code, not out of the goodness of our hearts, but for the business sense. It will happen sooner or later :-)
(and we have a few candidates lined up).

Right now we're trying to make the most of other peoples non-contributed code, and hopefully we will get to contribute our version back when we're finished. This relates to another point raised. The relative cost. For small contributions it is not worth the effort, unless you coded directly on uDIG as a small patch. But for bigger projects the relative costs might be small compared to the total project. I hope we can find such a situation with our printing work.

On Mon, Feb 1, 2010 at 2:52 PM, Andrea Aime <[hidden email]> wrote:
Riccardo Rigon ha scritto:

If you do find yourself working for a customer the ideas is roughly to trade reduced maintenance cost for the upfront cost checking with the community (perhaps a design to be reviewed from the PSC?).


i accept it (it is allowed), but I think it is a narrow perspective. The success of a software depends on how good it is. And the success of a company that (maybe among other things) develops that software is tied to the diffusion of the software (besides the ability of its management).  No software diffusion, no business. I think there is a trade-off between different needs, and a behavior that maximize the company fitness which is not the complete closure.

In an economic climate where companies try to just stay afloat the
long term perspective is irrelevant. You don't care about what would
happen in 3 years time if you don't know whether you'll still be
around in 6 months to 1 year.
If you ever worked in a software company you should know the number
one cost (usually the only significant one) is personnel, the moment
you hit a reduction in requests you start firing people, and everyone
remaining will do his best to show the company she's the last one
to fire. Talking about how open source will help in the long run
in such climate will get you fired sooner rather than later.


However, this is just my humble opinion.  For the community, I think it would be interesting to know an estimation of these  extra-costs, which maybe could be conveniently paid by other.

Depends. For small projects (5 days) it can be between 20-30% and
100%, for longer ones something smaller, like 20-30%.
It also boils down to how much you're respected in the community, how
good is the contribution you're providing in terms of code quality,
docs and testing. For some this can become an insurmountable roadblock.

Interacting with the community will also significantly slow you down
as you have deadlines, but everyones else is answering your mail
and posing concerns you have to answer to in their spare time.
A discussion that could be settled face to face in a couple of
hours can span two weeks. This is to not say you have two weeks
of overhead, but you have two weeks of delay and you'll have to
fill them with something else

There is also the problem of maintainance. If you just develop something
and plan to make it become core/supported intto a project, but you don't
offer long term maintenance you'll have to be lucky that someone else
is interesting enough and has time enough to care for your fantastic
contribution. Just offloading a contribution for a new functionality/module to a developer group
that's already very busy won't do much good. However, that's what
consulting companies often hope/try to do.



Cheers
Andrea


--
Andrea Aime
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

_______________________________________________


_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel
Reply | Threaded
Open this post in threaded view
|

Was: Re: Printing Reports in uDIG Is: Code Policies and Economics.

Riccardo Rigon
In reply to this post by aaime
Dear Andrea,

I thank for your contribution.  The Free Software World is good because everybody can express his/her opinions, and maintain his/her own. Time judges who survive, historians analyze the reasons of the surviving, and of the success.  

On Feb 1, 2010, at 2:52 PM, Andrea Aime wrote:

Riccardo Rigon ha scritto:
If you do find yourself working for a customer the ideas is roughly to trade reduced maintenance cost for the upfront cost checking with the community (perhaps a design to be reviewed from the PSC?).
i accept it (it is allowed), but I think it is a narrow perspective. The success of a software depends on how good it is. And the success of a company that (maybe among other things) develops that software is tied to the diffusion of the software (besides the ability of its management).  No software diffusion, no business. I think there is a trade-off between different needs, and a behavior that maximize the company fitness which is not the complete closure.

In an economic climate where companies try to just stay afloat the
long term perspective is irrelevant. You don't care about what would
happen in 3 years time if you don't know whether you'll still be
around in 6 months to 1 year.


This is, I repeat a myopic idea. If you have kids, you want them to survive much beyond few years. Do not matter what is happening now: you want to give them a long life. Unless your present situation is so dramatic that you cannot even think to the future.  From your email I deduce that the situation of your company is bad. This information does not make me happy. However, your company can die: but yourself can survive if the work produced in these years, is public, since, like the Phoenix, in this last case, you can built on that work. If the previous work is not public there is less chance that you can use your previous work to do it.

I am clearly joking.  However, for a company to survive, it needs to have revenues. The larger the revenues, the larger the probability of surviving, if obviously you accurately use and reinvest your money, and maintain the capacity of innovating. If someone robs  the revenues and escape (which is a common case in the current economics), again, you are dead. In theory there are more chance to die than survive. And the final results is that no one is eternal.  But here nobody wants eternity, but be able not simply to survive but pursue decent lives, and happiness, and propagate this possibility through other people and generations. 

This is the goal I pursue.  Not to be rich (I would have bought a television in that case ;-), and eventually I promoted myself as head of a political party in order to manage public money, just an example, without any possibility of realization, people are not so stupid)

But let's go back to the main issue.


If you ever worked in a software company you should know the number
one cost (usually the only significant one) is personnel, the moment
you hit a reduction in requests you start firing people, and everyone
remaining will do his best to show the company she's the last one
to fire.

I do not know if you really manage a company, but this certainly happens in life for who does. However, if you manage a Free Software company like any other company, probably you have missed something on the way. Not to say that any company promoting Free Software is an ONG.  Producing Free Software costs. Personnel cost. But I am not sure that wildly hiring people when the market goes up, and wildly firing them when the market goes down, is the right way to operate. I always believed that getting involved in Free Software was also matter of envisioning a different type of market, and a different type of company ... and possibly a different type of cooperation between companies. 


Talking about how open source will help in the long run
in such climate will get you fired sooner rather than later.


That's debatable. Let's see in five years from now.


However, this is just my humble opinion.  For the community, I think it would be interesting to know an estimation of these  extra-costs, which maybe could be conveniently paid by other.

Depends. For small projects (5 days) it can be between 20-30% and
100%, for longer ones something smaller, like 20-30%.
It also boils down to how much you're respected in the community, how
good is the contribution you're providing in terms of code quality,
docs and testing. For some this can become an insurmountable roadblock.


On that, I finally agree. However, for a mature community the rules should be codified somewhere. Not just source of interpretation. 


Interacting with the community will also significantly slow you down
as you have deadlines, but everyones else is answering your mail
and posing concerns you have to answer to in their spare time.


Agree. But it is a balance for what yo give and what you get. A living community is matter also of unselfish contribution. All of us had a lot from the community. You are asking yourself what you gave to the community. You should also ask what you get. And than deciding that the community ois worth to survive, and the survival of the community need some efforts. (You certainly give)


A discussion that could be settled face to face in a couple of
hours can span two weeks. This is to not say you have two weeks
of overhead, but you have two weeks of delay and you'll have to
fill them with something else

There is also the problem of maintainance. If you just develop something
and plan to make it become core/supported intto a project, but you don't
offer long term maintenance you'll have to be lucky that someone else
is interesting enough and has time enough to care for your fantastic
contribution. Just offloading a contribution for a new functionality/module to a developer group
that's already very busy won't do much good. However, that's what
consulting companies often hope/try to do.


I know that. and I fight everyday with that. We tried, unsuccessfully so far, to built countermeasure. But, we are still alive!



Cheers
Andrea


All the best,

riccardo



--
Andrea Aime
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel

________________________________________________________________        
Universita` di Trento         Dipartimento di Ingegneria Civile  e  Ambientale/CUDAM
Via Mesiano, 77, 38050  Trento      (ITALIA)                        
E-mail[hidden email]  
Ph: +390461882614-10    Fax:+390461882672
Publications according to ISI: http://www.researcherid.com/rid/B-5395-2008
JGrass (Open Source GIS): http://www.jgrass.org/
GEOtop (Open Source distributed hydrological model):  http://www.geotop.org/
_______________________________________________________________                                                      





_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel