Re: RE:Making Daffodil Replicator an Open Source : Suggestion
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 something with no expectation of any return, that is
Re: Making Daffodil Replicator an Open Source : Suggestion
On 18 Aug 2004, at 06:31, Simon Kitching wrote: To members of the incubator PMC: now would be a good time to speak up if you disagree with anything I've said! No way: you're doing perfectly fine. Thanks! /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Daffodil Replicator an Open Source : Suggestion
On 18 Aug 2004, at 12:29, Ashish Srivastava wrote: :0)Nice point. 20 developers will work part time (This figure could be 10, 15, 20 or 30) beacuse, as you said, there would need to be a critical mass of initial contributors. If there are developers out there who consider Replicator an exiting project to work on, then we wouldnt need to deploy this number. It could come down to 3 - 5 developers. I find this rather confusing. One of the criteria for exiting incubation is a *diverse* set of committers - i.e. an appropriate proportion of Daffodil for-pay developers but also non-Daffodil folks. If your idea of the original number of committers (coming with the donation of the project) varies between 3 and 30, I'm rather suspicious about who you consider to be a committer. Having no idea of the size of your codebase and your operations, I can tell you that the usual initial set of committers of other projects hardly ever surpasses 5 to 8 folks, and the rest will need to be voted in using common ASF procedures. You as a commercial entity have no control over this other than what is to be expected in a community project, and the Incubator will check whether you are following ASF guidelines. We do expect it be very successful; however, lots of work needs to be done on the same. Primarily, we need to ensure that Replicator can communicate with every known database server. Once that is done, a suitable business model (Red Hat, MySQL etc) can be built around it. The branding boost won't hurt either.;0) Just one thing ... Can we get some feedback from readers of this mail with regards to the provision of 'reasonable' attribution of code to the original author? To give you an idea about what is decent to add to an ASF distribution, have a look at the Cocoon CREDITS: http://cvs.apache.org/viewcvs.cgi/cocoon/trunk/CREDITS.txt? rev=30946root=Apache-SVNview=markup Apart from such a file, it will be hard to find other attributions in the Cocoon codebase linkable to a specific single commercial entity, since having these would carry a false sense of ownership over the code or project. Of course, our license permits repackaging and redistribution, so you could always redistribute a more commercially labeled version of the code through your own website, perhaps with some value-added services, bearing in mind that the ASF license requires you to link back to us as the originators of the code. Basically, Daffodil becomes Apache Daffodil, and it is up to you to build a business model around this publicly available ASF project, but the ASF will not serve as a daffodil.org entity alongside your daffodil.com. I hope I'm making myself clear here. You *will* be relinquishing control up to the level that you carefully need to check whether this is what you want. Another common issue is the inclusion of non-ASL licensed dependencies. The ASF currently has a policy of not redistributing LGPL/GPL-licensed code. Does your project depends on such code? Also, is there any way to assess what you are planning to donate? Lastly, I would seriously recommend you to approach the db.apache.org project as well, which might help you to recruit some sponsors and/or interested developers. HTH, /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[STATUS] (incubator) Wed Aug 18 23:45:23 EDT 2004
APACHE INCUBATOR PROJECT STATUS: -*-indented-text-*-
Last modified at [$Date: 2003/11/11 00:01:00 $]
Web site: http://Incubator.Apache.Org/
Wiki page: http://Nagoya.Apache.Org/wiki/apachewiki.cgi?ApacheIncubatorProjectPages
[note: the Web site is the 'official' documentation; the wiki pages
are for collaborative development, including stuff destined for the
Web site.]
Pending Issues
==
o We need to be very very clear about what it takes to be accepted
into the incubator. It should be a very low bar to leap, possibly
not much more than 'no problematic code' and the existence of a
healthy community (we don't want to become a dumping ground).
o We need to be very very clear about what it takes for a podling
to graduate from the incubator. The basic requirements obviously
include: has a home, either as part of another ASF project or as
a new top-level project of its own; needs to be a credit to the
ASF and function well in the ASF framework; ...
o Moving the bylaw documentation from the Wiki to the main site
o Merge the README.txt info on site management and the info on the
How to Participate page into a single place
o fix formatting of the project status pages
Resolved Issues
===
o The policy documentation does not need ratification of changes
if there seems consensus. Accordingly, the draft status of these
documents can be removed and we will use the lazy commit first,
discuss later mode common across the ASF for documentation
(http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]by=threadfrom=517190)
o Coming up with a set of bylaws for the project
(http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]by=threadfrom=517190)
o All projects under incubation must use a STATUS file (or a
status.xml file if the project prefers XML) that contains
information the PMC needs about the project. This file must
live at the root of the project cvs module
(http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]by=threadfrom=504543)
o Projects under incubation should display appropriate disclaimers
so that it is clear that they are, indeed, under incubation
(http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]by=threadfrom=504543)
The Incubation Process
==
This tries to list all the actions items that must be complete for a project
before it can graduate from the incubator. It is probably incomplete.
Identify the project to be incubated:
-- Make sure that the requested project name does not already exist
and check www.nameprotect.com to be sure that the name is not
already trademarked for an existing software product.
-- If request from an existing Apache project to adopt an external
package, then ask the Apache project for the cvs module and mail
address names.
-- If request from outside Apache to enter an existing Apache project,
then post a message to that project for them to decide on acceptance.
-- If request from anywhere to become a stand-alone PMC, then assess
the fit with the ASF, and create the lists and modules under the
incubator address/module names if accepted.
Interim responsibility:
-- Who has been identified as the mentor for the incubation?
-- Are they tracking progress in the file
incubator/projects/{project_name}/STATUS
Copyright:
-- Have the papers that transfer rights to the ASF been received?
It is only necessary to transfer rights for the package, the
core code, and any new code produced by the project.
-- Have the files been updated to reflect the new ASF copyright?
Verify distribution rights:
-- For all code included with the distribution that is not under the
Apache license, do we have the right to combine with Apache-licensed
code and redistribute?
-- Is all source code distributed by the project covered by one or more
of the following approved licenses: Apache, BSD, Artistic, MIT/X,
MIT/W3C, MPL 1.1, or something with essentially the same terms?
Establish a list of active committers:
-- Are all active committers in the STATUS file?
-- Do they have accounts on cvs.apache.org?
-- Have they submitted a contributors agreement?
Infrastructure:
-- CVS modules created and committers added to avail file?
-- Mailing lists set up and archived?
-- Problem tracking system (Bugzilla)?
-- Has the project migrated to our infrastructure?
Collaborative Development:
-- Have all of the active long-term volunteers been identified
and acknowledged as committers on the project?
-- Are there three or more independent committers?
[The legal definition of independent is long and boring, but basically
it means that there is no binding relationship between the individuals,
such as a shared employer, that is capable of overriding their
