[OSGeo-Discuss] Proposal to find an alternative to Collabnet

[Paul Ramsey]

The main migration pain I have seen (and even, experienced!) is not  
with source code, it's with the associated reference materials:

- Mailing list archives (not as easy as source code, but still not  
super hard)
- Documentation (easy if you manage it in CVS as docbook xml, for  
example, but nobody does that, they use...)
- Wikis and CMSs (you're screwed! they all seem different in just  
enough ways to make a clean migration will-nigh impossible)

The other painful migration tasks usually relate to things like  
continuous build farms and online demos, which require specific  
services set up on the host machines, etc.

P.

On 16-Jul-06, at 11:23 PM, Gary Lang wrote:

> Philosophy aside, I have to repeat what I've said in the past, it took
> us no time at all to migrate MapGuide from an internal Perforce server
> and Clarify bug tracking database to CN. It was absolutely  
> painless. And
> I anticipate that moving to something else in 6 months being similarly
> trivial.
>
> I would advocate new projects come aboard OSGeo. They'll be up in a  
> day
> and we'll have more critical mass of activity on the site. We'll all
> move together in 6 months.
>
> Otherwise we'll have 10 different sites. If that isn't a sandbox, I
> confess I don't know what is.
>
> Gary
>
> -----Original Message-----
> From: Jo Walsh [mailto:jo at frot.org]
> Sent: Saturday, July 15, 2006 12:55 PM
> To: discuss at mail.osgeo.org
> Cc: akelly at collab.net; brian at hyperreal.org
> Subject: Re: [OSGeo-Discuss] Proposal to find an alternative to
> Collabnet
>
> dear Cameron, all,
> On Sun, Jul 16, 2006 at 04:49:49AM +1000, Cameron Shorter wrote:
>> Ethically, I'd prefer to see Open Source projects use Open Source
> tools.
>
> Amen, brother! Open Source ideology dictates that application code
> wants to be free. Companies create "added value" by providing managed
> services built on free software. Clients stick around because the
> business relationship improves their lives, not because they're
> "locked in". So I've never understood why the CollabNet codebase is
> not managed on an open source basis; perhaps it would be more
> conducive to client loyalty (given CN's clients are software  
> developers
> with a itch to fix their own problems!) if it were.
>
>> Proposal:
>> =========
>> 1. I propose that Collabnet as it stands is not acceptable to be the
>> OSGeo Platform.
>>
>> 2. As a group we define what we require from a platform.
>> This page is a good start:
>> http://wiki.osgeo.org/index.php/Project_Infrastructure_Migration
>
> I agree that OSGeo needs a "Plan B" not only for the projects which
> are reluctant to migrate, but for those which are already committed,
> so that we can perform a real assessment of what value we are getting
> from CN / what the cost to us is of renewal, ethical considerations
> aside (though those are important and shouldn't be overlooked in a
> quantitative assessment!)
>
> http://wiki.osgeo.org/index.php/Tools_Spec was my attempt to look at
> this problem from a different angle. There is the 'checklist of tools'
> approach above, and that is invaluable in terms of not missing any
> pieces that every project needs to run well. There are tools that
> individual projects won't want or afford the overhead of, but that a
> foundation can provide collectively ("build and smoke" test farms...)
>
> There are other reasons why CN hasn't  been a good fit for OSGeo,
> where we should be providing more for our members and projects:
>
> - There's a great deal of interlinking / mutual dependence / mutual
>   redistribution between different projects - this is a byproduct of
>   being a 'stack' - where a prospective OSGeo user needs
>   Geotools+Geoserver+Mapbuilder, or GDAL+Mapserver+Mapbender, or
>   GDAL+OSSIM+osgPlanet, to build a whole application. What we've seen
>   of CollabNet's approach keeps projects in neat rigid sandboxes, and
>   that's not good for us - there's always been a lot of cross-project
>   developer energy and commitment - the foundation *arises* from that
>   and the tools should be reflecting it, not trying to engineer it
>   into existence (or failing to...)
>
> - There's a wider focus than on software - in educational resources
>   and geodata packaging and distribution which are indispensable to
>   getting open source geospatial tools into real peoples' hands. CN
>   doesn't provide tools for collaborative documentation management, or
>   processing / bandwidth for serious data munging and serving - so
>   OSGeo is obliged to look elsewhere for tools and hosting to do this.
>
> There's a System Administration Committee which was set up to look
> after, on a volunteer basis, the systems that OSGeo is getting free
> use of at telascience/SDSU. https://sac.osgeo.org/ The mailing list
> here might be a good place to have a focused discussion about
> what projects really need, and what visionary / next-gen tools the
> foundation could realistically be providing across projects.
>
> Cameron, one reason you "haven't heard a reasonable solution" is that
> it's no-one's direct responsibility to look after this; and not  
> only are
> all of us involved in OSGeo volunteering our time, but we're
> involved *because* we're *already* volunteering on other open source
> and open data projects ;) Personally i find it much easier to be
> reactive (like this ;) ) than proactive (like you :D ).
>
> The Board has been talking about hiring a full-time Executive  
> Director,
> part of whose responsibility would be to oversee / cat-herd the
> process of tools migration / support / 'solutions' what have you.
> But OSGeo needs some sponsorship commitment in order to be able to
> make believeable promises to any potential Executive Director about
> continuing to be given money on a predictable monthly basis. There  
> is a
> Fundraising Committee which is just starting to do its thing now -
> https://fundraising.osgeo.org/ . But of course, not only is everyone
> on the fundraising committee volunteering their time, but they're
> volunteering because ... and it's much easier to be reactive than ...
> and we keep looping around ;)
>
> thanks for the rousing,
>
>
> jo
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: discuss-unsubscribe at mail.osgeo.org
> For additional commands, e-mail: discuss-help at mail.osgeo.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: discuss-unsubscribe at mail.osgeo.org
> For additional commands, e-mail: discuss-help at mail.osgeo.org
>