RE:Making Daffodil Replicator an Open Source : Suggestion

2004-08-17 Thread Ashish Srivastava
Hi,

Thanks for the informative mail. It did go a long way in bettering my understanding 
with regards to The Apache Software Foundation.

However, based on your feedback, the following come to my mind:

>Firstly, the code you are considering releasing under an open-source
>licence is an add-on to a proprietory product. The ASF is unlikely to
>consider adopting that kind of project..

1. Daffodil Replicator is not an add-on to Daffodil DB (our Java database). It is a 
standalone product developed in-house by Daffodil Software. Daffodil Replicator use 
the standard JDBC driver interface to interact with databases. It is not interacting 
with any Daffodil DB's internal API. 

2. With regards to your comment about the 'group of developers' and the fact that the 
'code you are considering releasing can only be used with a proprietary database', the 
following: 
Replicator can be used by the following databases - SQL-Server, Oracle, Daffodil DB. 
(Note: These three databases have been tested with Replicator. I don't see why 
Replicator cannot be used with ALL others. However, testing needs to be done on the 
same.) Also, we can commit 20 - 30 developers from our talent pool, who can contribute 
from Day 1. Moreover, our forum (http://www.daffodildb.com:8080/forum) can be a good 
place to build up a pool of contributors.

3. Regarding Cloudscape, we are not sure if (or not) it provides support of Triggers 
and Multiple statements procedure (like PL/SQL in Oracle). If it does, we can ensure 
compatibility. (We would need some testing to be done, but that's not an issue.) On 
the other hand, if support of the said features doesn't exist, we can create the same. 
However, this would need access to the Derby source code.

4. Regarding our paradigm and business-model, we can (at this point of time) say that 
the objective for going the 'open source' way is singular: To build a robust product 
and a robust brand, at the same time leveraging the advantages of Open Source.

Regards,
Ashish Srivastava
www.daffodildb.com

PS: Please mark a CC to me for reply of this mail (although I subscribed the mailing 
list but I am unable to receive some mails)

Subject: Making Daffodil Replicator an Open Source : Suggestion
From: Simon Kitching <[EMAIL PROTECTED]>
Content-Type: text/plain
Date: Sat, 07 Aug 2004 13:10:17 +1200

On Sat, 2004-08-07 at 05:20, Nicola Ken Barozzi wrote:
> Ashish Srivastava wrote:
> > Hi,
> > 
> > We are a product based company named Daffodil Software Ltd, based in
> > India. We have developed many good products using JAVA out of which our
> > two premium product Daffodil DB (an RDBMS) and Daffodil Replicator
> > (database utility software) is largely accepted by world software
> > community.
> > 
> > We are planning to make our Daffodil Replicator an open source project.
> > 
> > How can we make it with www.apache.org please let us know how we have to
> > proceed.
> > 
> > I visited at http://incubator.apache.org but unable to find the answer
> > how to proceed in order to make our product open source. 
> 
> I'm cross-posting to lists where there might be interest in helping you 
> out on this.
> 
> > www.daffodildb.com

Hi Ashish,

The following is just my personal opinion, as a member of the ASF
(Apache Software Foundation); I am not speaking on behalf of the ASF.

I think it is great that you are considering releasing some of your code
under an open-source licence. I am sure there are a number of people
that are willing to offer advice on the process of releasing your code
as open-source. And if you do this, you are certainly welcome to reuse
the Apache Public License legal document as the base for the license
terms you release your code under; the ASF and its legal advisors
deliberately designed the license in a way that makes it easy for
non-ASF-hosted projects to use.

However if you are suggesting that the code you release may be hosted
and maintained by the Apache Software Foundation, I personally think
this is unlikely to happen.

Firstly, the code you are considering releasing under an open-source
licence is an add-on to a proprietory product. The ASF is unlikely to
consider adopting that kind of project. This doesn't mean that making
the code open-source is a bad idea, it's just something that the ASF
usually avoids being involved with.

Secondly when the ASF adopts existing code, the provider of the code is
expected to show evidence that there is a group of developers willing to
continue maintenance and development of the code in the future. Apache
doesn't want to end up hosting lots of code with no associated
developers. Given that the code you are considering releasing can only
be used with a proprietory database which does not have a large market
share, I think this will be a difficult thing for the Daffodil
Replicator project to demonstrate.

If your replicator tool can actually replicate data for multiple
different brands of database then please let us know; that would

Request for graduation and Lenya TLP

2004-08-17 Thread Gregor J. Rothfuss
Dear Incubator, dear Board,
The Lenya commiters, the Incubator PMC and our mentors (Stefano, Nicola) 
have voted unanimously to request for graduation of the Lenya project to 
become a Apache Top Level project.

Summary thread is here:
http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&by=thread&from=837762
The current status of the Lenya project can be found here:
  http://incubator.apache.org/projects/lenya.html
The Lenya web site:
  http://cocoon.apache.org/lenya
The resolution:
http://cvs.apache.org/viewcvs.cgi/cocoon-lenya/proposal.pmc.txt?view=auto
WHEREAS, the Board of Directors deems it to be in the best
interests of the Foundation and consistent with the
Foundation's purpose to establish a Project Management
Committee charged with the creation and maintenance of
open-source software related to content management, for
distribution at no charge to the public.
NOW, THEREFORE, BE IT RESOLVED, that a Project Management
Committee (PMC), to be known as the "Lenya PMC", be and hereby
is established pursuant to Bylaws of the Foundation; and be it
further
RESOLVED, that the Lenya PMC be and hereby is responsible for
the creation and maintenance of software related to
content management, based on software licensed to the Foundation;
and be it further
RESOLVED, that the office of "Vice President, Lenya" be and
hereby is created, the person holding such office to serve at
the direction of the Board of Directors as the chair of the
Lenya PMC, and to have primary responsibility for management of
the projects within the scope of responsibility of the Lenya
PMC; and be it further
RESOLVED, that the persons listed immediately below be and
hereby are appointed to serve as the initial members of the
Lenya PMC:
   * Edith Chevier ([EMAIL PROTECTED])
   * Dale Christ ([EMAIL PROTECTED])
   * Christian Egli ([EMAIL PROTECTED])
   * Andreas Hartmann ([EMAIL PROTECTED])
   * Rolf Kulemann ([EMAIL PROTECTED])
   * Gregor J. Rothfuss ([EMAIL PROTECTED])
   * Thorsten Scherler ([EMAIL PROTECTED])
   * Michael Wechner ([EMAIL PROTECTED])
NOW, THEREFORE, BE IT FURTHER RESOLVED, that
Rolf Kulemann
  be and hereby is appointed to the office of Vice President, Lenya,
to serve in accordance with and subject to the direction of the
Board of Directors and the Bylaws of the Foundation until
death, resignation, retirement, removal or disqualification, or
until a successor is appointed; and be it further
RESOLVED, that the initial Lenya PMC be and hereby is tasked
with the creation of a set of bylaws intended to encourage open
development and increased participation in the Lenya Project;
and be it further
RESOLVED, that the initial Lenya PMC be and hereby is tasked
with the migration and rationalization of the incubating PMC
Lenya project; and be it further
RESOLVED, that all responsibility pertaining to the incubating
Lenya project encumbered upon the incubator PMC
be hereafter discharged.

The charter:
http://cvs.apache.org/viewcvs.cgi/cocoon-lenya/charter.txt?view=auto
The Apache Lenya Project is a community project
developing open source content management solutions.
With strong foundations in XML-based server-side web application 
frameworks, like Apache Cocoon, the Apache Lenya Project consists of a 
group of people that share common values on collaboration-intensive
and community-based quality open source development.

The Apache Lenya Project is proud to share these values with its parent 
organization: The Apache Software Foundation.

The mission of the Apache Lenya Project project is:
- to provide commercial-quality, high-performance, well-tested,
standards-based XML editing environments that are developed in an open 
and collaborative fashion.
- to add user-oriented functionality on top of the Cocoon framework and 
other Apache projects.
- to advance the state of the art of content management and structured 
text editing.

-gregor
--
Gregor J. Rothfuss
Wyona Inc.  -   Open Source Content Management   -   Apache Lenya
http://wyona.com   http://cocoon.apache.org/lenya
[EMAIL PROTECTED]   [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: RE:Making Daffodil Replicator an Open Source : Suggestion

2004-08-17 Thread Simon Kitching
On Wed, 2004-08-18 at 01:13, Ashish Srivastava wrote:
> Hi,

Hi Ashish,

>  
> Thanks for the informative mail. It did go a long way in bettering my
> understanding with regards to The Apache Software Foundation.
>  
> However, based on your feedback, the following come to my mind:
>  
> >Firstly, the code you are considering releasing under an open-source
> >licence is an add-on to a proprietory product. The ASF is unlikely to
> >consider adopting that kind of project..
>  
> 1. Daffodil Replicator is not an add-on to Daffodil DB (our Java
> database). It is a standalone product developed in-house by Daffodil
> Software. Daffodil Replicator use the standard JDBC driver interface
> to interact with databases. It is not interacting with any Daffodil
> DB's internal API. 

Then that is *much* more likely to be of interest to the ASF. Thanks for
clarifying that.

>  
> 2. With regards to your comment about the 'group of developers' and
> the fact that the 'code you are considering releasing can only be used
> with a proprietary database', the following: 
> Replicator can be used by the following databases - SQL-Server,
> Oracle, Daffodil DB. (Note: These three databases have been tested
> with Replicator. I don't see why Replicator cannot be used with ALL
> others. However, testing needs to be done on the same.) Also, we can
> commit 20 - 30 developers from our talent pool, who can contribute
> from Day 1. Moreover, our forum (http://www.daffodildb.com:8080/forum)
> can be a good place to build up a pool of contributors.

That also sounds good. Knowing that multiple databases are already
supported is nice. An ongoing commitment from a contributing company to
maintaining the code will also be a good point in favour of your
proposal

There is one thing to keep in mind for the future: developing
open-source is different from developing "in-house". There have been
cases in the past where code has been released as "open-source", but the
development procedures of the original team have not adapted to the new
environment. In particular, the existing team need to be able to allow
others to influence decisions, must ensure all decisions are discussed
openly on email lists, etc. Open-source development really is a
different culture. I guess people who know more about this can provide
further advice if this goes ahead.

>  
> 4. Regarding our paradigm and business-model, we can (at this point of
> time) say that the objective for going the 'open source' way is
> singular: To build a robust product and a robust brand, at the same
> time leveraging the advantages of Open Source.

This really is a bit vague. If your company is really going to pay 20
developers to work at least part-time on a product that is downloadable
for free, the question "why?" immediately springs to mind. 

My current employer gave me permission to contribute some code developed
on company time to one of the Apache projects. This is because the code
was useful to us, but not something that gives us any competitive
advantage over competitors. By contributing, therefore, it cost nothing
but ensured that code we use was maintained and improved as part of the
project. 

This argument doesn't apply to you, though. From what you've described,
this tool can be used with many different databases. So what *are*
Daffodil's reasons for releasing this code you've paid people to create
as Open Source?

Do you want to make the company name "Daffodil" more widely known in
order to boost sales of your core product, ie you are using Open Source
as advertising? This is a perfectly reasonable motivation, but you need
to ensure that what you lose (loss of sales of this product + expenses
of development wages) are not greater than your gains. I'm not sure what
the ASF's policy is regarding including info on the original contributor
with future releases (I think they *do* provide reasonable attribution
of code to the original author, but you should check if this is
important to you).

Or do you regard the replicator as an add-on but not part of your core
products, and therefore want to share the development/maintenance costs
of this tool with other db suppliers?

Or do you think this replicator product will be wildly successful and
that as the original author you are well positioned to make money
providing support contracts for the open-source version (the "Red Hat"
model), or by selling "enhanced versions", or by selling the rights to
incorporate the code in other companies' proprietory offerings (the
MySQL model)?

Again, I am only speaking for myself here, but showing the reasons for
your release of code will help people believe that Daffodil is indeed
serious about ongoing support of the code and is serious about
transferring power over the project from itself to the open-source
community that may form around the project. Of course if your company
owners are simply motivated by goodwill to the world and willing to pay
developers to work on somethin