[Geoserver-devel] On breaking backwards compatibility

GeoServer GeoServer Developer
1

Hi,
seeing proposals that do break backwards compatibility, I believe it’s time to make it clearer as to why backwards
compatibility in GeoServer is very important (and breaking it represents a fatal mistake most of the time).

The common GeoServer deployment in public administrations is one or more GeoServer installations
being accessed by a variety of internal and external clients. The range of clients accessing the server
is vast and often completely out of control of the admins… because this is the nature of an interoperable
service, it does not talk with a specific client, it’s make to talk with everybody.

To give a small summary:

  • Internal users using one of the task specific web applications
  • Internal users with desktop clients (often different types, different departments might have different desktop clients, sometimes different versions of them, especially if the desktop client in question does not require a licence and the power user in question got the right to install programs locally)
  • Other internal services cascading or consuming the OGC service (SOA like)
  • External users, same as above but with a lot more variability
    The admins every now and then need to upgrade the server, be it because of security reasons, a critical bug fix, or because a new application requires extra functionality provided by a newer version.

When they do so, they need to ensure that everything else keeps on working… and that’s a lot of pain, because most of the clients above are outside of their control, even the in house ones:

  • Maybe a web application provided by a external vendor relies on some extra flexibilty (e.g., not requiring the version or service), upgrading it breaks it, but to fix the application a new contract with the provider needs to be setup (administrative and econominal issues arise)
  • Maybe an internal desktop client is in the same boat, but an upgrade of the client might require contracts, or verification that plugin X custom developed still works on the newer version, and so on.
    Long story short, doing upgrades requires a lot of verification, and the slightest backwards incompatibility just breaks havoc and makes the upgrade impossible (which, in case of upgrades related to security fixes, makes the situation untenable).

That’s why I keep on using a hard line on backwards incompatible changes, even when fixing a mistake: being “right” is not enough, operational continuity is more important than that.
That does not mean we cannot change stuff, but at least a fallback option to re-enable the previous behavior must be always provided.

Cheers
Andrea

PS: there is also a good read here https://en.wikipedia.org/wiki/Robustness_principle
To it, I’d add that on day one it’s good to be as strict as possible, but once the deploys happen, whatever
flexibility remained should be kept.

···

==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313

fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.

2

Hi Andrea,
Excellent points - I’ve seen such deployments first hand.
A prime example of backwards incompatibility between versions is the jump from Python 2 to 3. Python 3 isn’t entirely backwards compatible with 2 (refactoring is often required), so uptake of 3 has been considerably slower than for a minor version update.

That said, assuming GeoServer ever makes the leap to 3.x, it may be worth considering implementing sufficiently important backwards-incompatible changes then, like the Python folks did for Python 3.

Just my 2p,
Cheers,
Jonathan

---- On Fri, 17 Mar 2017 07:48:41 +0000 Andrea Aimeandrea.aime@anonymised.com wrote ----

Hi,
seeing proposals that do break backwards compatibility, I believe it’s time to make it clearer as to why backwards
compatibility in GeoServer is very important (and breaking it represents a fatal mistake most of the time).

The common GeoServer deployment in public administrations is one or more GeoServer installations
being accessed by a variety of internal and external clients. The range of clients accessing the server
is vast and often completely out of control of the admins… because this is the nature of an interoperable
service, it does not talk with a specific client, it’s make to talk with everybody.

To give a small summary:

  • Internal users using one of the task specific web applications
  • Internal users with desktop clients (often different types, different departments might have different desktop clients, sometimes different versions of them, especially if the desktop client in question does not require a licence and the power user in question got the right to install programs locally)
  • Other internal services cascading or consuming the OGC service (SOA like)
  • External users, same as above but with a lot more variability
    The admins every now and then need to upgrade the server, be it because of security reasons, a critical bug fix, or because a new application requires extra functionality provided by a newer version.

When they do so, they need to ensure that everything else keeps on working… and that’s a lot of pain, because most of the clients above are outside of their control, even the in house ones:

  • Maybe a web application provided by a external vendor relies on some extra flexibilty (e.g., not requiring the version or service), upgrading it breaks it, but to fix the application a new contract with the provider needs to be setup (administrative and econominal issues arise)
  • Maybe an internal desktop client is in the same boat, but an upgrade of the client might require contracts, or verification that plugin X custom developed still works on the newer version, and so on.
    Long story short, doing upgrades requires a lot of verification, and the slightest backwards incompatibility just breaks havoc and makes the upgrade impossible (which, in case of upgrades related to security fixes, makes the situation untenable).

That’s why I keep on using a hard line on backwards incompatible changes, even when fixing a mistake: being “right” is not enough, operational continuity is more important than that.
That does not mean we cannot change stuff, but at least a fallback option to re-enable the previous behavior must be always provided.

Cheers
Andrea

PS: there is also a good read here https://en.wikipedia.org/wiki/Robustness_principle
To it, I’d add that on day one it’s good to be as strict as possible, but once the deploys happen, whatever
flexibility remained should be kept.

–

==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313

fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.

Check out the vibrant tech community on one of the world’s most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

3

So the one I know of is the org.geotools.renderer.style.legacyAnchorPoint=true flag introduced for the GeoTools 17-RC1.

If we do want to preserve backwards compatibility we have some options:

  • configure this flag to true during startup
  • change the value based on strict=true (not sure how I feel about that)

In my experience the majority of styles do not use the default label position, often having to manually offset it from original point symbolizer. I kind of wish we got some feedback from 2.11-RC1 release.

···

On 17 March 2017 at 00:48, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi,
seeing proposals that do break backwards compatibility, I believe it’s time to make it clearer as to why backwards
compatibility in GeoServer is very important (and breaking it represents a fatal mistake most of the time).

The common GeoServer deployment in public administrations is one or more GeoServer installations
being accessed by a variety of internal and external clients. The range of clients accessing the server
is vast and often completely out of control of the admins… because this is the nature of an interoperable
service, it does not talk with a specific client, it’s make to talk with everybody.

To give a small summary:

  • Internal users using one of the task specific web applications
  • Internal users with desktop clients (often different types, different departments might have different desktop clients, sometimes different versions of them, especially if the desktop client in question does not require a licence and the power user in question got the right to install programs locally)
  • Other internal services cascading or consuming the OGC service (SOA like)
  • External users, same as above but with a lot more variability
    The admins every now and then need to upgrade the server, be it because of security reasons, a critical bug fix, or because a new application requires extra functionality provided by a newer version.

When they do so, they need to ensure that everything else keeps on working… and that’s a lot of pain, because most of the clients above are outside of their control, even the in house ones:

  • Maybe a web application provided by a external vendor relies on some extra flexibilty (e.g., not requiring the version or service), upgrading it breaks it, but to fix the application a new contract with the provider needs to be setup (administrative and econominal issues arise)
  • Maybe an internal desktop client is in the same boat, but an upgrade of the client might require contracts, or verification that plugin X custom developed still works on the newer version, and so on.
    Long story short, doing upgrades requires a lot of verification, and the slightest backwards incompatibility just breaks havoc and makes the upgrade impossible (which, in case of upgrades related to security fixes, makes the situation untenable).

That’s why I keep on using a hard line on backwards incompatible changes, even when fixing a mistake: being “right” is not enough, operational continuity is more important than that.
That does not mean we cannot change stuff, but at least a fallback option to re-enable the previous behavior must be always provided.

Cheers
Andrea

PS: there is also a good read here https://en.wikipedia.org/wiki/Robustness_principle
To it, I’d add that on day one it’s good to be as strict as possible, but once the deploys happen, whatever
flexibility remained should be kept.

–

==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313

fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.

Check out the vibrant tech community on one of the world’s most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

Geoserver-devel mailing list
Geoserver-devel@anonymised.com.366…sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
Jody Garnett

4

On Fri, Mar 17, 2017 at 10:04 PM, Jody Garnett <jody.garnett@anonymised.com>
wrote:

So the one I know of is the *org.geotools.renderer.style.legacyAnchorPoint=true
*flag introduced for the GeoTools 17-RC1.

If we do want to preserve backwards compatibility we have some options:
- configure this flag to true during startup
- change the value based on strict=true (not sure how I feel about that)

I think we can leave it as is. As I said in reply to Jukka already, I'm not
saying we should never ever break backwards compatibility,
but that it should be a concern and part of the discussion when making
changes, get a feel of what's the benefit vs damage ratio,
and remember, if at all possible, to leave a mechanism to re-enable the
previous behavior

In my experience the majority of styles do not use the default label

position, often having to manually offset it from original point
symbolizer. I kind of wish we got some feedback from 2.11-RC1 release.

Eh... I think us developers have the wrong mental model about this, and/or
the general lack of presence on the user list put off the (small) part of
the user community that would be inclined to just test for the sake of
testing.

Someone doing production is not going to test RC, they are going to wait
for an actual need to upgrade, and then go straight for the current
stable/maintenance.
I see real trouble on the user base side upgrading at our current pace, and
I'm not talking about the 6 months cycle, but the 1 year one (when a series
just goes out of support).
The common upgrade I see is from a number of releases back, I work with
organisations that is still based on 2.4 and one that comes
to mind which is still running 2.2, with no intention to upgrade in the
short term.

Also, I find myself sometimes looking at all the announcements between
version x and y to answer the question of "what does an upgrade buy me?"

From this point of view, and thinking about backwards compatibility issues,

I think it would be nice to have a single page with all
the main feature and backwards incompatible changes in each .0 release,
while it would not contain everything, it should
provide a useful quick summary for those making "long jump" upgrades.

Cheers
Andrea

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.

-------------------------------------------------------

5

In my experience the majority of styles do not use the default label

position, often having to manually offset it from original point
symbolizer. I kind of wish we got some feedback from 2.11-RC1 release.

Eh... I think us developers have the wrong mental model about this, and/or
the general lack of presence on the user list put off the (small) part of
the user community that would be inclined to just test for the sake of
testing.

Oh I know, and understand it is a cultural change over time. As more people
get comfortable with "just using" open source we are losing some of that
we-are-all-in-this-together rebel feeling that helped make this more of a
collaboration with developers/users. On the plus side we are now the
establishment - and have to worry about implementing a standard wrong.

Someone doing production is not going to test RC, they are going to wait

for an actual need to upgrade, and then go straight for the current
stable/maintenance.
I see real trouble on the user base side upgrading at our current pace,
and I'm not talking about the 6 months cycle, but the 1 year one (when a
series just goes out of support).
The common upgrade I see is from a number of releases back, I work with
organisations that is still based on 2.4 and one that comes
to mind which is still running 2.2, with no intention to upgrade in the
short term.

This six-month release / 1 year support cycle is of course subject to
change. Right now I find the balance okay from a maintenance standpoint -
but backporting is a fixed cost (it does not matter how many releases we
make, it matters how far back in time we have to backport).

TLDR: I know the user community would love a three year LTS release - but
we have not sorted out a way to make that profitable/sustainable/fun.

Also, I find myself sometimes looking at all the announcements between

version x and y to answer the question of "what does an upgrade buy me?"
From this point of view, and thinking about backwards compatibility
issues, I think it would be nice to have a single page with all
the main feature and backwards incompatible changes in each .0 release,
while it would not contain everything, it should
provide a useful quick summary for those making "long jump" upgrades.

That is something we can work on for the docs, there is an update page in
the geotools docs that could also use an update.

Cheers
Andrea

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313 <+39%200584%20962313>
fax: +39 0584 1660272 <+39%200584%20166%200272>
mob: +39 339 8844549 <+39%20339%20884%204549>

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.

-------------------------------------------------------

6

On Sat, Mar 18, 2017 at 6:09 PM, Jody Garnett <jody.garnett@anonymised.com>
wrote:

Oh I know, and understand it is a cultural change over time. As more
people get comfortable with "just using" open source we are losing some of
that we-are-all-in-this-together rebel feeling that helped make this more
of a collaboration with developers/users. On the plus side we are now the
establishment - and have to worry about implementing a standard wrong.

Meh... I have a different opinion about this one, the way I see it
developers broke the minimum level of "barter" normally seen on vibrant
open source communities, if I look at others I still see the occasional
user report that has one of the core developers step in and fix the issue
right away, which contributes to users enthusiasm and participation.
I don't see the same attitude in our developer group anymore.

Cheers
Andrea

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.

-------------------------------------------------------

7

I can see that also - our number of active developers has gone down, making that unsustainable. Chances are the truth is somewhere in the middle.

Still the approach is the same, attract more developers so we have capacity to improve.

···

On 18 March 2017 at 11:42, Andrea Aime <andrea.aime@anonymised.com> wrote:

–
Jody Garnett

On Sat, Mar 18, 2017 at 6:09 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:

Meh… I have a different opinion about this one, the way I see it developers broke the minimum level of “barter” normally seen on vibrant open source communities, if I look at others I still see the occasional user report that has one of the core developers step in and fix the issue right away, which contributes to users enthusiasm and participation.
I don’t see the same attitude in our developer group anymore.

Cheers

Andrea

–

==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313

fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.

Oh I know, and understand it is a cultural change over time. As more people get comfortable with “just using” open source we are losing some of that we-are-all-in-this-together rebel feeling that helped make this more of a collaboration with developers/users. On the plus side we are now the establishment - and have to worry about implementing a standard wrong.