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.
<redd...@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
