> He's already using cvs there. Enabling it to be public for others to > use and view the code in, is a single toggle. It in _no way_ changes any > steps involved with the way he's already using it. It doesn't "increase" the > complexity in any way at all.
I'm NOT using CVS at all, so it's not a "single toggle". > You forget that making the project public, encourages others to look > at the code, use it, repurpose it, borrow pieces from it, improve it, etc. > If you only care about making it a one-person project, why put it on a > collaborative site like SourceForge, which is wrapped around facilities that > encourage community contributions (bugtracking, forums, news, cvs, etc.)? > You could just as easily keep all the code "in-house", and just put the > release tarballs (or .exe files in this case) on an ftp site for others to > download when there are new releases. Opening the source does not automatically mean you're inviting others to contribute. I admit I'm using SourceForge solely for their web and file hosting. Nevetheless, JPluck meets SF's project requirements. > My only complaint is that now, the only way to obtain the source, is > by running a proprietary operating system and extracting it on that system, > so that it can be used on other platforms. If that is his model, he should > change the licensing to reflect that, as he has done in the past. The changes made to pre13 only affect Windows-specific functionality[1]. I don't think it's necessary to make that code available on other platforms and I don't see how this should affect licensing. That said, I will create a separate source distribution in the future as I'm doing now with JPluck 0.9. My main reason for bundling the binaries and source is ease of distribution. Call me lazy, but releasing files on SF is a tedious process. On a side note: I plan on porting JPluck's document creation library to C++ sometime in the future(i.e. not anytime soon). The main reason is to make it feasible to embed plucking functionality in other applications without incurring the steep overhead of a Java VM. Examples include an XPCOM component for Mozilla and an ActiveX control for use in Win32 applications. (This does not mean I'm throwing Java out the door entirely, though, the library can be embedded in a Java app as well.) My intention is to make this a more collaborative effort, as C++ is a good deal harder than Java and having more hands on deck will definitely be welcome. Regards -Laurens [1] http://jpluck.sourceforge.net/jpluck2/docs/changelog.html _______________________________________________ plucker-list mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-list
