Thoughts: "Is base16 going away? I really like Base16 the way it's always been."

[joshgoebel]

I want to be clear I'm not speaking for the whole organization, these are definitely my thoughts, and feedback is welcome. - hence my tagging this discussion and help wanted. Though at the end I suggest that it could be beneficial if the entire organization decided on clear messaging around this topic. It's possible the choice of Base17 as a name was poor. To me it only implies "the next version", not "base16 original flavor is dead"...

So I've seen concern around the various direction/directions we're talking about regarding Base17/BaseNext DRAFT. It's for sure a more featureful vision that allows for a lot of additional flexibility, better application support, higher fidelity porting of existing themes, better interop with other theming formats, etc... and with that yes, it adds a bit of complexity - though I don't think too much. (given all the benefits) But I wanted to address concerns...

---

Some portion of these concerns boil down to:

Base16 is simple, it works great, I like it as-is. Don't change it or take it away from me!

Chris still owns base16, so we actually can't change it - only Chris can. I'm also not sure anyone is trying to take Base16 away from anyone.

I've personally never wanted to replace base16 - and I personally don't think that should be a goal for the organization either. Base16 is great for many use cases, it has evidently existed since 2012 largely unchanged (esp the style spec, the schema spec)... In places where it's already shines it's possible it will still be shining 10 years from now.

Anyone who wishes to continue to author base16 schemas and templates - or use the resulting themes: If you like exactly what base16 has to offer, great. I have no plans to drop support from the Node builder - and there are plenty of other base16 builders besides. Ever since Chris chose to keep Base16 separate the vision I (personally) have is of lots of theming systems that can interact and co-exist together... base9, base16, base24, ansi16, baseNext, [pick almost any outside theming system with semantic meanings tied to colors, insert here]...

I don't think it's a zero sum game. Vim and VS Code both exist, both with vibrant communities. I'd like to hope our first "next thing" is compelling and gets many people truly excited and chomping at the bit to upgrade - but if you aren't one of those people, that's ok. I'd encourage us as an organization to consider making a clear statement to the effect of:

• We aren't trying to kill base16 0.2 or take it away from anyone.
• We aren't trying to co-opt or replace base16 0.2.
• We'll continue to support base16 0.2 (as it's part of the broader theming community)
• Instead, we're trying to build next generation systems for those who desire more than what base16 offers.

Yes, fixing our naming issues will help with some of this, but I think it's one piece of the puzzle, not the entire puzzle.

Thoughts?

---

Edit: Replaced many places of base16 with base16 0.2 to clarify I'm talking about the style/schema/templating spec largely - though I'm not sure it helps. 😕 Another reason that the current way the spec is split out is confusing for referring to "point in time" versions of a style system. It really feels like base16 v0.2 should be sufficient but really I need to instead say : base16 0.2 style guide plus base16-builder 0.9 (schema/template details but not builder detail) Ugh.

[joshgoebel]

I do think our overall vision here has implications for how we handle some things like base16-schemes, etc... for example the path I'm suggesting would likely have us leaving base16-schemes alone (or the base16 folder if we go that route)... it would continue to serve as a convenient "aggregate" for all base16 schemes as long as it proved a helpful resources... and the next generation of schemes would be their own discrete thing...

So the talk would switch from "upgrading" all the schemes (or the entire repo) to instead creating new variations that support all the new features, and leaving the old base16 olds as they are...

[belak]

I'm going to try and sum up what we've talked about in IRC before:

1. We have no plans to continue developing "base16" under that name. Out of respect for Chris, what he built, and what we're guessing his wishes are, we will leave that name alone.
2. Base17 will be a "hard fork" of base16, starting at the last version supported by Chris's base16 (before he cleared the repo history). We will continue making incremental improvements to this format. We will also try to make sure our builder spec also supports all the same variables as Chris's base16 builder spec to make migrating templates easier. In theory, any base17 color scheme would be usable with base16 templates (because they will both work with the same palette of 16 colors), so any base16 template maintainers would be able to continue developing with our builders and continue to get any improvements we make and new color schemes we add for free.
3. Our next-gen theming system (currently codenamed Base Next) will aim to be a much more flexible system, and will be a much larger departure from base16. This would potentially allow porting color schemes like Nord more faithfully.
4. Eventually, we'd like to move towards alignment with Base17 and Base Next - the goal would be for both to support the same semantic aliases (Proposal: Semantic color aliases (both official and theme defined) #11, Official list of semantic color names to support #24, Idea: Support full ANSI schemes with 'semantic' colors #36, Epic: Semantic color "slots" plan #48). This will allow any templates we build to reference the same semantic aliases and work for Base17, Base Next, and other future palettes we work on, rather than having to build separate templates for each system.

The short version is that base17 will be "our version of base16". I'd also imagine we will continue to develop Base17 and Base Next at the same time.

[joshbode]

possible suggestion for the project name - base0x10 :)

[AFulgens]

My 2¢ about the whole story (seen through issues #51 and this one, additionally prompted through #36 and #44). I'm indifferent either way.

• Base16 was and always will be a brainchild of Chris', it's open source and decentralized by nature, nothing can change that.
• There are legitimate reasons today to centralize it and create a de facto standard based the ideas of Base16. I even support such centralization, as long as it stays OSS.
• I don't care what happens with the two terminal repositories "maintained" by myself. Console2 and ConsoleZ are at best described as dormant and will most probably never see widespread usage ever again with the prevalence of VSCode and Windows Terminal. The term "maintainence" is also silly for these two, as the templates have been generated once and since then are sitting there in the repo, without any changes at all.
• I personally (personal opinion incoming!) find Base17 a bit of a silly name, better would be Base16++, Base16Next or as suggested by @joshbode base0x10 or a similar play on the original. Base17 will most probably cause confusion for new adopters as it will not contain a color scheme of 17 different colors. Think of all the freshmen in college, who will have to dive into obsure historical details, when they want to find out why is 17 in the name!

[joshgoebel]

Think of all the freshmen in college, who will have to dive into obsure historical details, when they want to find out why is 17 in the name!

Isn't this why history is fun? 😎🤓 I'm no longer super invested in what the new name is... I see good arguments all around for many of the possibilities suggested. To avoid further "conflict" with Chris I do slightly prefer a name without "Base16" in it though.

[belak]

I'm closing this for now, since it's not really actionable, but please feel free to open issues if you have any other questions or comments.