Fellow GeoTools developers,We have been working together for many years now, all compromising along the way in order to keep working as a group. Over this past year or more, our collaboration has been increasingly strained which has been a drag for everyone. While we share the vision of building a geospatial library, we differ greatly in our visions of what it takes to make a great library, in our priorities and constraints, and in our ways of working. Thanks to all of you who, like us, tried repeatedly this past year to find a way to work together: it was worth the effort to see if our differences could be resolved.
Unfortunately, we have reached an impasse. Some of us believe that a library offered for general use should be of consistently high quality, be coherent within itself, be correct with regards to the base contracts of the language, and should exist on its own merits. The importance of this is apparently not shared and we have been unable to restore GeoTools on the path of becoming an independent, reusable geospatial library. This difference in vision has caused a great amount of friction within the GeoTools project and exacerbated differences in project governance styles and personalities. The recent response to Martin's offer of using his 'Geotidy' work as the basis for GeoTools3 convinced us that these differences were now fundamental. Martin was proposing to embark on a new major version of the library which would be based first and foremost on code quality, coherence and correctness. He was offering to fold back his past nine months's worth productive work on his modules, bringing an updated, cleaned, more coherent and better performant base to the library as the renewed foundation for GeoTools. Martin was even volunteering to help back port a copy to Java 5 because of the constraints of the external Geoserver project. The response both suggested that the new direction was not welcome and that the PMC would be used to impose its will on the whole community. Rather than continue to struggle to align these two different visions for the geospatial library, rather than fold ourselves to the new centralized vote based decision making process, and rather than continue a collaboration that was no longer fun, we are profiting from the freedom that everyone has worked so hard to give to all our users and to each other and we are setting out in a new direction.
Monday we will publicly announce the emergence of the Geotoolkit project, a formal fork of GeoTools, which aims to build a geospatial library by maintaining a clean, well documented, and coherent code base.
Geotoolkit has essentially the identical aims to the original GeoTools2 project---building a world class, free software, Java language library for geospatial applications based on the broadest standards accepted by the geospatial community, notably those published by the OGC and ISO. Geotoolkit differs principally with the current GeoTools project in requiring that the core library contain only well written code which is coherently using the base functionality, properly documented in javadoc, and correctly following the contracts of the Java language. To ensure this, Geotoolkit has adopted a different working approach leveraging the new Mercurial tool for decentralized collaboration, affirming its independence from any particular user community, and restructuring the governance model towards a technical meritocracy.
Geotoolkit is free software: you can find daily builds from the project website at
http://www.geotoolkit.org/
and get the source code from
http://hg.geotoolkit.org/
by performing a mercurial clone of the base library
hg clone http://hg.geotoolkit.org/geotoolkit
to obtain a full, independent history of the Geotoolkit project itself
and generate working copies of any revision locally. Also available on
the mercurial site are the repositories:
* gt_on_geotk, a version of GeoTools with core portions
ported to the Geotoolkit base,
* gt_modified, a modified version of the ported GeoTools
which contains conflicting changes,
and
* geotoolkit-pending, providing new extensions intended
for Geotoolkit itself but not yet formally reviewed for
correctness,
coherence and quality.
These versions of GeoTools use a different prefix for the jar files to
ensure they do not conflict in maven repositories or elsewhere. As
time permits, we expect to review the code in both gt_modified and
geotoolkit-pending for integration into the core Geotoolkit library.
The Geotoolkit project does not yet have any formal charter or any codified rules of operation---we will invent these as we grow and we discover ways to help all contributors keep working together productively. For now, the project has adopted the Mercurial distributed versioning system which we expect to solve many of the issues of collaboration on such a complex project. Third party users will be able to integrate the changes they choose along with their own modifications, all on a schedule which suits them.
Developers will have access to version control locally but be able to share their work once it is mature and ready. Multiple lines of development can emerge, each following its own constraints, yet able to collaborate when desired. Like other projects, we have found distributed version control systems to be a major step forward in the management of free software projects.
Geotoolkit arises from the need by some members of the community to work on a clean, modern, high quality code base coupled with our inability to move GeoTools itself in that direction by inspiring changes either in its governance, in its versionning tool, or in its review policy to ensure code correctness, coherency, and quality. Martin launched out on a major effort at cleaning the code base in order that he have the code he needed himself and hoping that by doing the first wave of work he could inspire a new direction for GeoTools. The response to his recent offer to re-integrate his work suggested that there was no consensus for such a direction within GeoTools. That has lead us to fork off the new project Geotoolkit.
Last summer, Martin set out to clean the GeoTools library completely aiming for close to zero warnings from the compiler and build tools, intending to remove almost all deprecated code, planning to transition to the current version of the Java language, and planning to improve the code along the way. He started with his own modules for which he planned, along the way, to fix JIRA bugs, integrate contributions committed into his modules prior to his review, and refactor some internals. Martin started with a clean, empty repository and copied every GeoTools file, one by one, into this new repository ensuring that the full repository stayed clean, that the code was well integrated with the rest of the library, that the whole code base would compile with close to no warnings and that the API documentation and core web site could be built without intervention. This 'Geotidy' project resulted in a well documented, coherent core for the GeoTools library which could be built completely and deployed every night.
Martin's expressed intent in undertaking this work was that this should be the start of a project wide effort to strive for a higher quality library. Because of this new goal, the use of the Java6 platform, and the scope of the changes, the transition seemed major enough to suggest that this work, if it were adopted by the community, would form the basis of a new major version of the library and would become Geotools3. Martin has periodically announced updates on his work on the mailing lists and during face to face meetings and kept his running list of major changes both on the JIRA issue tracking system:
http://jira.codehaus.org/browse/GEOT-2117
and on the automatically built web site:
http://geotidy.geomatys.fr/build/tools/gt-migrate/changes.html
to document his progess. His aim was always to bring this work back as
the basis of a renewed GeoTools although he has been exceedingly
careful to stress that he would offer, not impose, this direction to
the project.
When Martin had completed the work on his modules and offered to merge this work back into GeoTools as the basis of version 3.0 of the library, the response made it apparent there was no excitement or consensus from other participants on this new direction. This lack of shared vision suggested, on its own, the need for a new project but it was also coupled with ever increasing differences in vision of the role expected from the Project Management Committee, of the proximate purpose of the library, of the importance of adopting new tools, and of the importance of code review and integration in the overall viability of the project. For several of us, the experience confirmed that the GeoTools PMC has drifted towards a fundamentally new vision of its role in the community. Where the rules governing the project state, in the 'Roles and Responsibilites' chapter of the developer's guide, that: Module maintainers are the lifeblood of GeoTools. They own a specific module and make the majority of project decisions related to their module. In GeoTools, module maintainers have the most direct responsibility and say over the code in the project, via their module.
http://docs.codehaus.org/display/GEOT/3+Module+Maintainers
the PMC was now arguing that Martin did not control his modules. Where
the developer's guide says:
The PMC makes all decisions that cannot be resolved by module
maintainers. The PMC strives to make as few technical decisions as
possible, preferring to leave technical decisions to module
maintainers and a general consensus process.
http://docs.codehaus.org/display/GEOT/4+Project+Management+Committee
the PMC was asserting its right to veto Martin's work rather than
seeking out a path by which the work could proceed. For us, the PMC
had expanded a "Proposal" process originally aimed at ensuring changes
to the unmaintained main module would be well considered to establish
its control over the entire project through a right of veto over any
change to core code. Most troublesome, the standard decision making
process for technical changes was assumed to be the vote of the six
members of the PMC not the consensus of the community as a whole.
The experience followed worrisome trends in the evolution of the
approach of integrating new functionality, in the relation of the
library to third party projects, and in the overall quality of the
code. The increased use of bindings to C language libraries for
important functionality suggests a possible departure from the
original vision for the library as a Java based effort. The work
suggests more of a scramble to add new functionality than a well
structured approach to extending the library. GeoTools has also
increasingly become a project driven to support the needs of the
GeoServer project rather than a project aiming to stand on its own
merit. GeoTools currently only makes a release when a new version of
GeoServer is about to be released while the suggestions for adopting
an internal release policy have been rejected. GeoTools is still using
Java5 only because that is what GeoServer needs despite the
developer's guide rule stating:
Our policy is waiting for a dot release before migrating to
new version of the Java language.
http://docs.codehaus.org/display/GEOT/2.1+Language
while Java6 is now up to its thirteenth release. The PMC is now
dominated by developers primarily affiliated with the GeoServer
community. Perhaps most importantly, the library itself is in poor
shape with no indication that things will improve. The repository is
full of code of completely different quality, production level code
mixed with experiments, the build regularly breaks, the javadocs can
only be generated through painful hand holding, the automated web site
cannot be built, and the code elicits a huge number of warnings from
both integrated development environments and build tools.
The experience followed the lack of desire to adopt new policies for project independence or use new tools to facilitate distributed collaboration. The repeated calls for adopting an autonomous release policy, possibly based on regular time based releases were rebuffed. The suggestion over the past year of moving towards a new decentralized code versionning system were also rejected as too complicated.
The experience followed a long term failure of the project to find a way to properly integrate new work with the rest of the code base. Internally, the project has been struggling to add functionality as fast as possible without finding a way to ensure that different parts of the library are coherently using the same base functionality, are adopting similar strategies and dependencies, and are not duplicating pre-existing code. Similarly, new developers have always been welcomed with open arms but then left to develop their own work in their own space without the project finding a way to properly mentor new commers and review and integrate their new work with the rest of the library.
Over the past year or two, these issues have repeatedly returned without us finding a way to resolve any of them. This has resulted in an unfortunate trend of all our discussions turning into argument. That has led to an ever decreasing level of cooperation, to fewer productive discussions on the mailing lists, to increasingly infrequent community discussions on irc, and to much of the discussion happening off the lists. These differences, it seems, are hurting the project deeply, are reducing the value of the collaboration, and turning a project which should be fun into a constant drag.
Given our separate visions of the importance of code quality, coherency, and correctness, given the differences in project governance, management, and tooling, and given that the collaboration has stopped being as fun as it should be, it seems best for everyone if we part ways and fork Geotoolkit into its own project so that both our visions can evolve as each group desires.
While we are taking a fork in the road, we do so without ill will. We have, over the past years, had fun, had productive discussions, learnt a great deal from each other, and brought GeoTools through five major versions up to version 2.6. We hope GeoTools remains productive and useful to those who wish to use it and keep working on it.
GeoTools could also, of course, transition to use Geotoolkit if it ever wishes to do so. If the code were suitable unmodified, GeoTools could simply use Geotoolkit JAR files through a Maven dependency. More likely, if GeoTools needed its own modified version of the library, it could host its own mercurial clone of those libraries. GeoTools could then, on its clone, add any deprecated methods which have been removed but which GeoTools still needs, backport the code to Java5, or make any other changes it wishes. Depending on the complexity of the changes, mercurial could even make it simple to periodically update that clone to integrate upstream improvements in Geotoolkit.
All the best and happy hacking, the Geotoolkit founders
smime.p7s
Description: S/MIME cryptographic signature
------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects
_______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
