Messagekit: JSQ Branding Separation from MessageKit

[TheDarkCode]

This project began in part because of the deprecation of JSQMessagesViewController, but that does not mean it is simply JSQMessagesViewController rewritten in Swift. While there is some degree of expected migration to this project from JSQ, it is not about making a drop-in 1:1 replacement. While a lot of healthy architecture discussion has already been happening, we are also already seeing predictable confusion bubbling to the surface. It is going to be very repetitive having the same discussions over and over if we don't settle this very early on.

“Growth is painful. Change is painful. But nothing is as painful as staying stuck somewhere you don't belong.” - Mandy Hale

So far a core philosophical difference in the future of this project has arisen due to this overt relationship with JSQMessagesViewController: Are we devoted to Swift and the innovative future it offers with increasing developer support, or are we making legacy-code support a primary goal by requiring Objective-C compatible interfaces and APIs?

We cannot satisfy both without such things as: making sacrifices in the long-term design, architecture, and optimizations; adding complexity to the style guidelines for contributions; and allowing the continuation of an endless stream of debates regarding Objective-C vs Swift legacy support.

So far this project has already started to adopt components of JSQ's likeness and even a part of its following. I think while it is very healthy to use the past project's successes as inspirational guidelines for what is right and should be carried forward, it is equally unhealthy to let the past dictate the progress to be made by letting is hover over everything like a superficial target to live up to. If people want JSQMessagesViewController they already have that option or one of its numerous forks. We don't need to rehash every issue, debate, discussion, or decision that was made with regards to JSQMessagesViewController in the context of legacy support or its compliance with Objective-C specific implementations.

What I propose is that we make a clear distinction going forward: either we are inextricably linked to JSQ's APIs and legacy support requirements in some form - thereby embracing the confusion already created, or we are an independent project without any explicit requirements tied to past implementations or architectures of other libraries other than Apple's own.

If we are going to make the distinction clear, that means making at least a few decisions right off the bat:

• No reuse of things like the JSQMessagesViewController logo on the organization or project. We should have a distinct look and feel that represents this project not a rehash of the past. Even if the change is simply the choice of color on the logo, it is better than keeping it as-is. Reusing the same logo unaltered is bound to further embroil us in confusion as to the overall expectations and direction of this project.

• Rephrasing the organization's description from _"In-progress: A community-driven replacement for JSQMessagesViewController"_ to something which directly addresses the overall focus of the project, not just one of its inspirations. That means something like "A community-driven messages UI library for Swift."

• Style guideline inclusion limiting any use of the JSQ prefix anywhere in the MessageKit library. If any prefix is to be used, it should be MK.

• Any documentation that was used in JSQMessagesViewController should not be reused word for word to prevent search engines from adding additional confusion.

• JSQ API formats should be treated explicitly as guidelines not absolutes. That means, we should not be arbitrarily scoping development to require compliance with any of the past project's decisions. This is essentially about making it clear that we are not solely focused on keeping external API continuity while reworking internals. This is a ground-up refresh of everything to deal with the changing requirements of the next 4-5 years, not a perfection of what the requirements were in the past. JSQMessagesViewController supports iOS 7.0 and above, but we should not be expecting or considering anywhere near that same level of compatibility with older versions of iOS. As such, no breaking change should be off the table due to legacy support or anything regarding versions of iOS prior to 9.x or 10.x. If people want to target those older versions, they already have options. We do not need to be another.

[SD10]

@TheDarkCode The problem is this project is quite literally:

_"A community-driven replacement for JSQMessagesViewController"_.

There will be no JSQ prefixes or any personal name prefixes. This project is about MessageKit and the MessageKit organization as a whole. I want everyone who contributes to the project to feel a sense of ownership.

It won't be a mirror image of JSQMVC, but still a suitable replacement. The fact that we're a new project allows us to make different design decisions and remove architectural constraints that were present in JSQMVC. We'll treat JSQMVC as both an inspiration and a learning experience, but not an immutable guide.

As for removing any other "JSQ branding", the logo is definitely staying. It doesn't reference JSQ in any way, Jesse is simply the one who provided it. I believe this to be a neutral logo and I happen to like it a lot. Call me a tyrant but this is one of the few things not up for community discussion 😃.

I recently added a VISION.md in hopes of clearing up some of this confusion. I believe you will find the answers to other points you touched on there.

[TheDarkCode]

Keeping the logo detracts from the countless other repositories that also influence the work done here, yet were not part of JSQMessagesViewController. Arbtirarily scoping this to be all about JSQ eliminates a lot of the creativity and opportunity ahead.

This is a very poor decision in my opinion.

[MacMeDan]

I think @TheDarkCode has some good points here. I think there were good intentions with using the old logo but it causes more confusion when it comes to this project. I fell like we really do need to break away from the JSQ ideology and open ourselves up to our own path. I am also a fan of dropping support for anything below 10. If that wants to be added later that is fine (except it will continue to help less and less people).