Available from GitHub ~ be sure to grab the zip package in the releases section. Any bugs please raise an issue in the repository and I’ll get to it as soon as possible.
Now on to building a companion plugin and start on another theme (after some sleep of course) 
@zulfgani thank you for this! Still a ways off, but it will be great to have some examples of themes in the ClassicPress theme directory “right out of the gate”.
I am curious about this theme’s use of the Acid Framework. I haven’t done much with the Customizer, what are the difficulties it addresses? Do you use this in all of your themes?
Glad to be able to contribute in any which way I can. Got a few more ideas themes and plugins scheduled by the summer
This is the first time I’m using it. I had planned on not have any options in the theme due to all other frameworks being a heavy load. This is the lightest I could find that didn’t pack too much fluff. I also liked how easy it was to spin up the options with a few data configs.
I think the Customizer is an underrated and under used piece of software. I hope to take as much advantage of it as possible in all my future development.
Nimble Page builder did a great job with the Customizer but their code is a mess to work through, no structure to it. Another good example is the tailor page builder, a bit primitive but great use of the API.
Okay. One reason I asked about the Acid Framework is I’m not sure if that would be something we would want to include into ClassicPress core or not. There would be two potential difficulties there - code review (we need to review all code that goes into core pretty carefully) and licensing (Acid is GPLv3 while ClassicPress is GPLv2, and I am not sure if the two can be mixed like that).
As we are considering moving the Customizer into a core plugin could that not be bumped to GPL 3 and then merge in the desired framework?
Personally I would have thought for a core Customizer plugin Kirki would be a better choice as it packs a tone of features which Acid is no where near. Provided of course if MIT can be combined with GPL 2/3
Are we? This would be a much larger amount of work than moving other features to a plugin, so at the moment it seems unlikely to be done for ClassicPress v2. XML-RPC for example mostly lives in a few isolated files, but the Customizer seems more “sprawling” from what I have seen.
Why does the customizer need another framework on top of it?
Uhmm… I seem to recall somewhere in the forum or slack that the Customizer was one of the abstraction being considered. I must be reading too much 
I read that as an intent to extend the Customizer, not the case?
No, sorry if I wasn’t clear with my original message! If a theme includes an extra framework around the Customizer, that’s fine, but that means it is probably not a good candidate for inclusion into ClassicPress core as a default theme, since we would have to also add this framework into core.
Hence my question around why these frameworks are necessary. Are there problems with the existing Customizer APIs that these frameworks help to address?
Ah OK. I think I see where the confusion is 
GeneriK is a separate theme in relation to the proposed default theme. The proposed theme is a fork and has the default Customizer functions in it and was released under the terms of the GPL 2, so no issues there.
GeneriK was conceived as a derivative of 2017(CSS), underscores(Markup), Genesis(Inspiration) and a theme I had created for WP namely Actions(Ideas). Actions was sold to a well known themes shop so I’ve taken the experience from there and applied to this new theme.
If however the committee and community wishes to consider GeneriK as a possible default candidate 
then yes, I would have to refactor the Customizer code and drop the theme to GPL 2
Alright. I think you would know better than I would which themes are likely to be well-suited for a default theme. I expect we’ll revisit that discussion as we get closer to v2 release.
In the meantime, everyone reading this, please try out these new themes (GeneriK and the Storefront fork) and let us know what you think!
One thing I saw when reading through the code for GeneriK that I really liked: lots of actions and filters. This makes it easy to override just about any aspect of the theme that one might need to customize in a child theme.
