Hi Chintan, Reading through your proposal, I have one main point to make.
At the Apache Software Foundation, the people who lead the projects are the people who do the work on them. We use the wrong word "meritocracy" to explain this principle; a better word would be "do-ocracy." http://www.apache.org/foundation/how-it-works.html#decision-making https://incubator.apache.org/guides/participation.html#as_a_developer https://communitywiki.org/wiki/DoOcracy That means that your project can completely proceed on its own if it wants to; the only thing over which you're not in control is whether that project gets to call itself CouchDB or not. That decision is reached by the people who have built CouchDB into what it is today. ----- On that last point, there's a lot that would need to be done for you to convince the PMC that your vision is the one, true future of CouchDB. What you propose is both a significant rewrite, as well as requiring an entirely new set of skills from the developer base (Rust, MQTT, Kotlin, Swift). It is in direct competition with the proposal being worked on this list for the FoundationDB backend swap. With the addition of MQTT, it sounds like the entire replication protocol and methodology would need to be revisited, as the semantic changes you're proposing would break existing client replication. Finally, the proposal to push into the mobile space would directly compete with our sister project PouchDB, who have put in tens of thousands of development hours as well. This all adds up to a much bigger scoped project than CouchDB is today, and I daresay may be bigger than I think even you realize. With my PMC hat on, I have to ask: * Do you already have developers versed in these skills you can bring to the project (beyond yourself)? Are they ready to commit the 40+ hours a week each to making it a reality? * Do you have experience in building a distributed system of this scale, using the specific technologies you propose? * How do you plan to convince other developers of your approach specifically? * How do you intend to train up our existing developers on the new languages and technologies involved? * How do you perceive the advantages and disadvantages of your approach *specifically* vs. the FDB approach already outlined? -Joan On 2019-07-09 10:28, Chintan Mishra wrote: > Hello team!! > > Years of time and effort help move a product to the heights that CouchDB > has reached. And as a non-contributor, rather a very new CouchDB > user(1.5 years) who failed to find some relevant emails, I came up with > a version of the future for CouchDB that I thought would help us grow. > But Jan and Robert helped me realize that it takes a village to raise a > child(CouchDB). So this is a proposal to find a middle ground from where > we are headed and where the market is going next. The proposal I wrote > was solely driven by what I have read over the years about the growth of > the product and the community. I have attached the file or if you prefer > reading in a browser, then click here <https://gitlab.com/snippets/1873543>. > > It will roughly take 4-5 minutes of your time. A proposed direction is > to start an entirely new project. That is not what I desire. I want to > join the community behind CouchDB not build a new one using it. My goal > from this proposal is to generate leverage by creating early mover > advantage and help grow the community. > > Thanking you. > > -- > Chintan Mishra > Rebhu Computing > Founder and CEO
