A request

[LanceNorskog]

I would like to request a philosophy statement, or statement of purpose, for the Keras framework. It would address things like

• A backend must support all features in a list before we will bless it
• A new or existing function must be documented before it goes in the API
• Policies for backward compatibility

[fchollet]

A backend must support all features in a list before we will bless it

We will release a separate repository containing the formal API specification for Keras, as well as tools to check API compatibility for a specific implementation. This should address this point.

A new or existing function must be documented before it goes in the API

This is naturally enforced by the code review process.

Policies for backward compatibility

This would normally be handled on a case-by-case basis during the RFCs process for API change proposals. "Backwards compatibility" is listed in the RFC doc template as one of the topics to be covered.

[bhack]

@fchollet Can you expose your updated position about this.
Now Keras It Is going to be a single backed project and soon or later we will have Keras = tf.keras.
So what Is the case of still having a separate governance instead of a simple SIG inside tensorflow, having RFC with the other RFC in Tensorflow etc.. Instead of having a separate keras-team orgs like It Is still a totally separate/indipendente project.

I think that a some quite near point Keras will be only an historical name of a multi backend python only API but de facto will be just a namespace inside tensorflow python API.
I suppose that at some point nobody will think that we need to reserve a specific tf.Keras namespace in the python tensorflow API if It Is the default/reccomended API.
At some point users will start to think about why we have a specific namespace for Keras API subset inside Tensorflow.
So to summarize all this separation will make sense in a multi to single backend transition phase.
But then I think It will start to create some ambigiuty to have a sperare "project" for something that It Is not separate anymore or at last It Is just the High level API sig in Tensorflow.

[juliangall]

As a new user, I'm already confused by things like this https://keras.io/getting-started/functional-api-guide/ and this https://www.tensorflow.org/guide/keras/functional

It makes it very difficult to know where you're supposed to look and what is up to date or not.

[bhack]

@juliangall As a new user what Is your feeling on reading the release note about Keras and tf.keras (expecially the bold sections):

https://github.com/keras-team/keras/releases/tag/2.3.0

[juliangall]

Until reading that I didn't think about Keras not being the same as tf.keras. I hope you can see that someone who has not been involved with the history of this is a little confused. I do fully understand that this is a rapidly developing area and that much of this is unavoidable. I can see that Keras was independent of Tensorflow and was/is an API for other products too.

However, when you're coming to this new, you aren't concerned with how everything got here. I am using Tensorflow/Keras and I see it as a single product. I need to type tf.keras.layers.Dense but it would be more logical to me to type tf.layers.Dense.

I don't want this to seem like a criticism. These fantastically powerful tools are made available for us all to use for nothing. One can only be grateful for all the effort that goes in from many people, paid and unpaid.

[bhack]

/cc @dynamicwebpaige @ewilderj cause this is a cross keras/tensorflow topic.
Expecially, cause we had some other activite thread outside python perimeter like @dhruvrajan:
https://github.com/dhruvrajan/tensorflow-keras-java
tensorflow/community#168

And in Keras sig and tensorflow-dev google groups mailing-lists about the role of Keras namespace/API like of the namespace It will be a marketing High level design philosophy/brand across language/TF subprojects etc.. I.e. we know and declare in docs that in TF.js was designer with high Keras API care but It doesn't adopt Keras namespace and so on...
Instead on jvm seems they want to use Keras brand/namespace/API but adapted to java etc.
I really like Keras since caffe2/Theano times but I think that It Is something to handle with care also by a marketing/strategic point of view expecially when newcomers will start to be in a consistent ratio to "old school" users/Devs/researchers.
I hope that we are not going to create some new confusing boomerang strategy.

[bhack]

Read also https://www.pyimagesearch.com/2019/10/21/keras-vs-tf-keras-whats-the-difference-in-tensorflow-2-0/

[bhack]

/cc @joanafilipa @ewilderj

[bhack]

There was some update in yesterday Keras-sig meeting. Meeting notes are still not available but mainly seems that there will be and effort to centralize Keras stuffs over this GitHub organizzation/repo.
In the single backend roadmap (TF only) I cannot see the separate GitHub Org as a winning strategy. But probably I have not the full overview to evaluate this.
It Is just my impression but it will be really difficult to explain to new TF users why we have organized ourselves in this way and why we use the keras brand/namespace in a separate org as Keras is only used in TF and expecially only in the Tensorflow "core" project.
Then we have only API mimic in other project (TF.js) without "promoting" keras brand/namespace. Still very confusing for newcomers IMHO.
Newcomers will not understand things like "TensorFlow.js layers API for Keras users" that we offer at https://www.tensorflow.org/js/guide/layers_for_keras_users

[bhack]

See also the fragmentation activity in ticket/threads like:
keras-team/keras-contrib#519 (comment)

[gabrieldemarmiesse]

@bhack I understand your worry. After tf.keras has been moved to keras-team/keras, we'll be able to judge if that is indeed a long term problem. For the moment it's a bit messy. The decision has been taken. If we believe that it's still a problem a year after the move has been made, we can juste move repositories to the tensorflow org. Moving a full repo between orgs is actually easy, while extracting tf.keras from tensorflow is not.