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
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 make the project much more interesting,
