Reimplement all Inbox features or Migrate to GMail design or Stop project maintenance about inboxer

[jonatandorozco]

We're gonna continue project development! All issues related with reimplementation of Inboxer features are gonna be listed on:

https://github.com/denysdovhan/inboxer/milestone/2

[swidnikk]

I'm looking for an Inbox email client to use after Google walks away... I really can't use gmail—too complex and distracting. If this group decides to reimplement—lmk because I'd love to help support.

[denysdovhan]

Reimplementing Inbox features might be a hard task, but we can split it in a few sprints, adding those features gradually. This will help to gather old Inbox user in our application and make a good product from this.

Migrating to GMail design is simpler, but a useless solution. There are tons of desktop email clients with far more better UI.

Stop project maintenance is gonna be a bitter solution — it's always sad to kill your own projects 😢

[Reklino]

I feel the same as @swidnikk. I've been considering starting an open source project that aims to be a thoughtful evolution of Inbox, keeping true to the principles that made it such a beloved product. I'd be interested to see what direction this group wants to take this project, and would love to help if that's the direction this project ends up going.

[denysdovhan]

@jonorozcoc could you please add a link to this issue in README.md's banner, to pay user's attention to this issue?

[jonatandorozco]

@denysdovhan What do you think about maintaining two branches?
The 1.x.x for implementing new features
The 2.x.x for implementing current Inboxer features (up to 1.1.5) and then integrate new features of 1.x.x

Eventually people will move to 2.x.x branch the next year and 1.x.x branch is gonna be closed

[denysdovhan]

@jonorozcoc yeah, LGTM.