[fdo-internals] Dropping off PSC

[Leaf Li]

I think there are some misunderstanding here. So I want to highlight some of points.

1. Both Greg and I agree that getting the MITAB changes reviewed and submitted back to the originating SVN depot is a good idea.

In Greg and my email, we both think non-fork strategy is a good thing. In my email, I introduced the issues of MITAB that I met when I try to implement MapInfo FDO Provider. So my points of view is to change MITAB directly for now in order to implement one powerful MapInfo FDO provider. It is my point of view. You can agree and disagree with it. However, the issues of MITAB that I met are true. 

So my points is the more important thing for now is how to resolve those issues. 

2. MapInfo FDO provider was developed by me and Aleck, and did not correspond to an Autodesk high-level initiative.

Greg already mentioned it. I want to add more. 

MapInfo is one of most widely used GIS products in China. Moreover, I see some email discussion whether we should have one MapInfo FDO provider in FDO open source community. So I think maybe I can implement one. So I and Aleck made some study and implemented one MapInfo provider prototype based on MITAB. We did it using our spare time. So it is a personal behavior at the beginning. Recently I told PM and Autodesk high-level. They are interested in it and think it makes sense from a business perspective.

So I really think "getting something done now by Autodesk overrides cooperation" isn't true. Maybe it is better to modify it as "getting something done now by Leaf overrides cooperation". 

I admit it is better to communicate MITAB developers before I did prototyping. However, I did not do it because of the following reasons.
* The last update date of MITAB homepage is April 21, 2008. It isn't updated for two years. So my impression is that nobody maintains it.
* When I implemented MapInfo provider at the beginning, I play it for fun and don't know whether I can implement it and when I can finish it because I took my spare time to do it. So I don't think it is necessary to communicate with MITAB developers.
* I don't know Daniel Morissette has some changes for read/write access although he said he had been in touch with some people at ADSK interested
in MITAB r/w support 2-3 year ago. If it is introduced in MITAB homepage, I think I definitely will contact Daniel Morissette.
* I also think getting the MITAB changes reviewed and submitted back to the originating SVN depot when I implemented MapInfo FDO provider. I think it isn't late when I have some initial results. 

When I wrote RFC, I really don't think it makes sense to mention those information in RFC. Maybe it is the root cause of confusing and misunderstanding.

3. Nobody already makes a decision to fork MITAB. 

"your decision to fork MITAB (for those who don't know yet, I am the original MITAB developer). In my opinion, none of the technical reasons expressed in RFC 54 and in the thread earlier this week on this list warrant a fork."

I have to correct the Daniel's statement. In RFC 54, I mention need to MITAB modification and don't mention forking MITAB. I have to clarify that nobody makes a decision to fork MITAB. In my email, I mentioned I prefer to having a separate MITAB. It is my point of view because I want to resolve MITAB issues that I met. However, my preference does not mean that the community cannot have a discussion or input on how to best 'open-source' the code, including the MITAB pieces. FDO project uses RFC process and PSC will vote to decide the final decision. 

Finally I want to say I don't think the most important thing is whether we should fork MITAB. The most important is how to resolve MITAB issues that I introduced in my email and RFC. I am completely open for other options if they can resolve those issues.

Hope my explanation can reduce some misunderstanding and confusing.

Thanks,
Leaf Li

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Daniel Morissette
Sent: Saturday, October 30, 2010 5:02 AM
To: FDO Internals Mail List
Subject: Re: [fdo-internals] Dropping off PSC

Greg Boone wrote:
> Well, as for MITAB, I too am in favor of a non-fork strategy. I would like to see the code moved back to the original repository. Maybe a further discussion could be undertaken by the members of the FDO community on how that can be accomplished. 
> 

Hi Greg, and PSC,

I'm sure you realize how disappointed I am after reading this FDO RFC 54
and your decision to fork MITAB (for those who don't know yet, I am the
original MITAB developer). In my opinion, none of the technical reasons
expressed in RFC 54 and in the thread earlier this week on this list
warrant a fork.

I'm glad you're in support of returning the code to MITAB, but hopefully
you realize that contributing back is not as simple as dumping a mega
patch on me or other MITAB/OGR devs. Each change needs to be reviewed
and considered in light of its impacts on the library, its users, and in
this case on OGR since it is used as part of OGR as well.

Just to make things worse, I have some unreleased code here in the
development version of MITAB that sets the bases for random update...
not much yet because the project for which I was doing it (unrelated to
FDO or ADSK) got canceled a while back, but I've put some thinking into
it and have some code already. It's a shame that nobody asked me before
working on a fork, you could have started from my dev version instead of
the latest public release... now instead we are in presence of a real
fork since my changes for read/write access are very likely incompatible
with those made by Leaf and Alex... just more headaches to deal with for
a potential merge.

(For the record, I had been in touch with some people at ADSK interested
in MITAB r/w support 2-3 year ago and had told them that I was working
on it already... that was before this other project got cancelled... so
I am in part to blame for never releasing a version of MITAB with r/w
support after saying for several months that it was coming... but I
still wish someone had talked to me before forking.)

> 
> That being said, whatever options are proposed needs to have a realistic chance of funding, support and maintenance going forward. Autodesk has, and is currently providing support and funding in areas where it feels it gets value for its money, In doing so it supports maintenance of fdo and the current list of providers, builds, defect fixes, etc. The King organization does the same. I would like to see more individuals and organizations advocate for their interests as well, fund appropriately, and champion their requirements and needs in a similar manner. 
> 

Very good point, but open and proactive communication doesn't cost that
much.

I'd also add that the chances of myself or another MITAB or GDAL/OGR dev
putting energy into a merge of an eventual mega-patch after the fact
will also depend on available funding.

Daniel
-- 
Daniel Morissette
http://www.mapgears.com/
_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals