I have to register with Andrea under the dissenting opinion here. The "invent here" policy does not sound like a good idea to me. In fact, it seems to eliminate one of the great benefits of the Java language, widespread use of popular and task-specific programming languages. If you want to use a "every project roll their own solution" philosphy, start programming in C. :]
Seriously folks, there is no way I'm going to spend two weeks, or even a week, working on some code that already comes packaged in a JAR that I can download and add to my classpath in about 30 seconds. Not only that, but as soon as you roll your own solution you eiliminate a team of developers with expertise in a certian aspect of the Java rogramming language. Take Joda as an example, how many programmers do we have that now Time/Calendars like the Joda guys? How much time can you sock to Time/Calendar programming challenges. The Joda guys do it every day... I think we are attempting to treat a problem with the wrong medicine. If dependencies are an issue in GeoTools let's look at a better system for organizing dependencies. Can I see a list of the dependencies of each module and the JAR version within a couple mouse clicks? How do we decide as a group to move to a new version of a library? Can we package the libraries used by the majority of our modules into a convenient download for our users? I think the policy should be to avoid libraries that provide duplicate functionality, not to avoid use of libraries. For example, it seems silly Landon On Mon, Jun 30, 2008 at 7:10 AM, Andrea Aime <[EMAIL PROTECTED]> wrote: > Jody Garnett ha scritto: >> I was looking at the "how to import a shapefile" page on the wiki - and >> it mentions the "do not invent here" policy and how that has lead to our >> massive amount of dependencies. Here are some ideas on how to set up a >> "positive" invent-here policy. >> >> How about this for a GeoTools 3 where live is beautiful etc... >> >> GeoTools 3 should adopt an "Invent here" policy: >> 1) unless a dependency offers significant benefit we should roll our own >> - A dependency that brings in additional dependencies is a bad thing >> - A dependency that is used by several modules is a good thing >> 2 Significant benefit is measured in weeks not days >> - if you want to use Joda time it better offer more functionality than >> we can expect you to code in in two weeks. If you are using a couple of >> functions we can probably expect you to be able to code them up in 13 >> days... you do after all have Joda time to serve as an example. > > Ideally this looks like a very good idea. > > In practice I don't know how I can justify spending 2 weeks of > resources when the same work can be done in 2 hours. > > Turning two weeks into a monetary evaluation, even assuming a > low rate of 500USD per day, that's 5000$ (assuming only 10 days, > the working days in two weeks)... can you justify > that much with your customers to avoid a dependency? > > Or if you want to turn that into a pure open source metric, > let's assume someone that, like me, was working only in > his spare time after work and in the weekends, someone > being able to work the equivalent of 2 days per week > on gt2. That turns the effort into an effective 5 weeks. > Do you believe this is reasonable, especially for someone > that's coding "for fun"? I don't think so? > > Cheers > Andrea > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________ > Geotools-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geotools-devel > ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
