couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chintan Mishra <chin...@rebhu.com>
Subject Re: [DISCUSS] A direction from a non-contributor
Date Wed, 10 Jul 2019 16:40:58 GMT
On 10/07/19 9:55 PM, Chintan Mishra wrote:

> On 09/07/19 9:33 PM, Joan Touzet wrote:
>
>> 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.
> I appreciate that you shared these links. I now understand what I have 
> to do next.
>> -----
>>
>> 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).
>
> From Slack conversations, it appears the community has some 
> inclination towards building a Rust based CouchDB some day. As for 
> other technologies those changes are not happening today. I do not 
> propose to start with all the changes at once. Storage engine is a 
> good place to start.
>
>>   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.
> The HTTP replication protocol more or less remains the same in the 
> foreseeable future. A new MQTT replication strategy will be built upon 
> the existing method. The two will not work in parallel. Either one of 
> these will work per database.
>> 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.
> The community will evolve at some point. And bringing people from 
> sister project onto CouchDB will allow faster development. The diagram 
> in the proposal missed a part for Web Browser based CouchDB. This 
> missed part is an interface for JavaScript and CouchDB-Web Browser. 
> So, we will need some JavaScript developers too. And they can help 
> improve Fauxton.
>>   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.
>
> I do realize that I want CouchDB to be in a billion mobile and 
> embedded device by 2025. I understand this is a challenging scale. I 
> brought this here because I see how much we need a DB for a "Cluster 
> Of Unreliable Commodity Hardware". I assume proposed path will take 
> somewhere between 18-21 months to come to fruition for a team of 15 
> people working 40 hours/week.
>
>> 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?
> No, I do not have a team in place for this.
>> * Do you have experience in building a distributed system of this scale,
>>    using the specific technologies you propose?
> I have been reading about distributed systems. I want to take up an 
> Open Source project which solves replication problem for devices 
> coming up with emerging technologies.CouchDB is the best fit as it 
> already solves theproblem of replication across remote devices.
>> * How do you plan to convince other developers of your approach
>>    specifically?
>
> What got us(you) here, won't get us(you) there! -- Marshall Goldsmith
>
> CouchDB led the way by being years ahead. This is just the same thing 
> happening again in a newer market. CouchDB is already great at 
> replication. What I am proposing is taking this simple-but-powerful 
> methodology a step further and building it for planetary scale 
> use-cases(idea derived from Lasp-Lang).Here are some ways with which 
> we drive more developers, users, and eyes.
>
>  * Helping users realize that CouchDB lets them relax while building
>    applications for devices with any form factor.
>  * Reaching out to the developers who have built their own solution for
>    replicating stuff from their device of any form factor to CouchDB
>  * On-boarding developers who will become early adopter and test it out
>    on their IoT devices. Thus, proving an unmet market need.
>  * Promoting offline-first strategy among mobile and embedded
>    developers will drive contributors from these communities.
>  * Documenting comparisons between existing mobile and embedded
>    solutions which provide replication solutions like Realm, and 
> CouchBase.
>
>> * How do you intend to train up our existing developers on the new
>>    languages and technologies involved?
> If people are excited about the future they are building then this is 
> a smaller problem to tackle. People in this community when and if they 
> come to a consensus about the proposal then this can be tackled by 
> 'Each one, teach one' followed by Yamaha Motors. This is a buddy 
> system where people get new partners to tackle a problem/PR. They 
> share issues, their understanding of the codebase and language, etc. 
> with each other. As buddies rotate everyone gets on the same page 
> after a few cycles. I have found 3-pair buddy system works best in 
> software.But this may differ based on culture, language, timezone, and 
> availability.
>> * How do you perceive the advantages and disadvantages of your approach
>>    *specifically* vs. the FDB approach already outlined?
>
----
> Value addition (Horizontal) > >
> ----
> Proposal (Vertical) \/ \/
>
> Pros
>
>
> Cons
>
> FoundationDB
>
>
>  * Improving what works for majority of existing users
>  * Iterates CouchDB to a better form
>  * Prospect of immediate consistency for ACID transactions
>
>
>
>  * Losing some small and mid-sized developers
>  * Fragments community
>
>
> Polyglot-unification
>
>
>  * Growth by tapping newer prospects
>  * Reduces fragmentation of user community and codebase
>  * Reimagines CouchDB as if it was built in 2019
>
>
>
>  * Tons of work
>  * Uses RocksDB, overlooks FoundationDB migration
>
----

I didn't know that table is not supported on this email server. So here 
is what I meant.

Proposal Name: *FoundationDB*

Pros:

  * Improving what works for majority of existing users
  * Iterates CouchDB to a better form
  * Prospect of immediate consistency for ACID transactions

Cons:

  * Losing some small and mid-sized developers
  * Fragments community

Proposal Name: *Polyglot-unification*

Pros:

  * Growth by tapping newer prospects
  * Reduces fragmentation of user community and codebase
  * Reimagines CouchDB as if it was built in 2019

Cons:

  * Tons of work
  * Uses RocksDB, overlooks FoundationDB migration

>
> Email with subject "CouchDb Rewrite/Fork" by 'Reddy B. 
> <reddy.b@live.fr>' has mentioned some other concerns. This proposal 
> introduces a new story for CouchDB. This proposal would require using 
> RocksDB instead of FoundationDB.
>
>> -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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message