Northern Post — The state and roadmap of Nord #183

svengreb · 2023-02-18T23:22:33Z

svengreb
Feb 18, 2023
Maintainer

First, thanks for all the great contributions, support and nice feedback 💙
Nord was born as a small personal project, designed to fill the gap for a color palette that matches my preferences and tastes, and has grown into a really large and broadly used project.
Sometimes it still feels a bit unrealistic that it grew up to this size and the maintenance overhead that comes with it, but I enjoy every day I can work on this project. It reminds me of why Nord is great with the way it got so far.

I‘ve planned and continuously worked on this post for a really (really!) long time to finally reveal plans, answer questions, propose ideas and clarify many topics that were previously documented in many different forms on many different platforms in many different formats.
To prevent you from being hit by a wall-of-text™ you can use the table of content below (click to expand) to simply move to the sections you‘d really like to read when you‘re not interested in all of the topics, but please note that some sections overlap or reference content from others.

Table Of Content (click to expand)

The History of Nord
Behind The Scenes
- Identity & Branding
The Ecosystem
The State Of Things
Sponsoring
The Future Plans

The History of Nord #

Origin #

Almost every developer cares about the development setup to suit all the needs and personal preferences and that also includes color themes. This often applies to IDEs and editors since these are mostly the main tools and make up the majority of the time.
In my case I had come to a point where I decided to finally “beautify“ my setup in a way I can really enjoy it instead of ticking off a lot of things with a “fits first, I‘ll do the rest later“. I was working on my tool stack and was already quite satisfied since it worked great and I got things done, but I often switched between different color themes.
“There is absolute no public theme out there that you like?“. Well, like I said there have been some themes I used on a daily basis, but it was more like a “works for now“ solution.
So Nord was born out of affect because there was no other project that could fulfil my (maybe too demanding?) requirements.

Design Inspiration #

Even though I don‘t even live close to an “arctic“ zone (or maybe because of that), and also prefer warm days of the year, I‘ve always been fascinated by the ambience of snowed up and frozen areas. They produce such a calm and clean aura. And even if it‘s just an optical illusion, I also always associate it with a bluish appearance. During night times, or polar nights, the beauty of Auroras resembles a miracle and looks almost surreal with the blaze of colors.
My decision to develop a color theme based on this motto was therefore made quickly.

Sixteen Out Of Millions #

As unspectacular as it sounds, but I composed the colors of Nord in a trial and error process. The concept of creating “mathematically correct“ color palettes was never an option and all colors are “hand-picked“. For me, using an algorithm to calculate the base colors of palettes is something that can be left to machines, but creating palettes for humans is something that AI will never be able to do.

It is important to note that at this time the main goal was to decide only on the actual colors first. This differs from a color “theme“ in that there is no mapping of a color to a specific meaning yet. This is also where you have to decide about the actual amount of base colors. I wanted to create the themes for my terminals first so the decision to go with 16 colors was fairly simple.

Polar Night #

I‘ve always got along better with darker color themes so my first step was to define base colors that will act as background, starting with the darkest color. With the goal to use something that resembles the bluish appearance of the arctic, the dark colors should contain a higher proportion of blue. The result was nord0 and the brighter ones nord1 to nord3, which all together make up the “Polar Night“ palette.

Snow Storm #

For an arctic appearance, of course, snow must not be missing. As a contrast to the colors of the “Polar Night“ palette I‘ve created the colors nord4 to nord6, which all together make up the “Snow Storm“ palette. Here, too, the base is bluish to match the idea of Nord.

Frost #

Of course the “heart palette of Nord“ must be the one that contains the main “bluish“ accents. The colors should represent the different color spaces of the various types of ice and their appearance when they are refracted by rays of light. The goal to choose colors that vary in their contrast and brightness was also important to enable the use of these among each other and to cover a wide range of visual distinctions. The result was nord7 to nord10 which is known today under the palette name “Frost“.

Aurora #

In order to create a good color palette, it must always cover a wider range of colors but not only the accent color and the ones that match in hard contrast. Like mentioned in the “Design Inspiration“ section above the almost surreal blaze of colors of Auroras matched my imagination of the palette topic. After reading and watching a lot about these natural wonders the colors nord11 to nord15 were born as a result of many hours of meticulous color grade adjusting and testing. Of course the name for the palette was clear right from the beginning: “Aurora“.

Naming #

Building the color palettes took multiple weeks with a lot of dogfooding through prototyping with port projects for my personal favorite applications, but afterwards there was still one open question: what should it be called?

“There are only two hard things in Computer Science: cache invalidation and naming things.“
— Phil Karlton

Of course the basic idea was to reflect the inspiration topic of the color theme in the name, but it should not be too banal. Another criterion was that the name should be short and “crisp“, a good and proven concept so that it can be quickly remembered.
I came up wih a lot of names that are easy to interpret for everyone who understands English, but basically almost all were very generic and none of them had anything special about them. So I started over, but this time with the style of foreign language names in mind. I collected words from my native language German and started to play around with their spelling without losing their meaning.
In the end I decided for “Nord“, inspired by the “Norden“ which is related to the Old High German nord, both descending from the Proto-Indo-European, meaning “left; below“ as north is to left when facing the rising sun. I liked this name best when I first wrote it down and it fits perfectly with the criteria of length and memorability.

Underestimated Importance Of Color Themes #

Many people don‘t give much relevance to topics like matching color themes, but as a developer it often plays a big role. If someone asks you why it matters that much to you or why you don‘t simply use the default theme of an application, just reply with “Why is it important to you which manufacturer your car comes from when it is just supposed to take you from one place to another?“ or “Why do you care what your clothes look like as long as every other piece of clothing also serves its purpose?“.

A pleasant highlighting of textual content is not all because the matching appearance of pure UI elements actually rounds off the whole ambient.
Although the colors of different text elements actually seem so trivial, it subconsciously plays a major role in many aspects such as productivity and even the personal mood.
The tools and applications used on a daily basis are usually “the developers best digital friend“ and workflows are built on top of them. So in the end it is important for the productivity. There are no limits when it comes to applying a theme to a whole environment, including any application or even the operating system, to set up your environment that works best for you.

My goals with Nord were part of these facts and are part of the idea on which it is built.

Growth #

In the beginning the main focus was to create a theme that fits my personal needs and works for my tool stack and setups. It was a visual style that worked for me without having to hope that others have already created a theme for an application that I use or evaluated to use. I could be sure that the appearance will meet my expectations as I can use my own color theme. So over time, I adapted all applications of my tool stack and was satisfied with the result.
Since I‘ve always been an absolute advocate of the open source concept, of course especially for software, I decided to make Nord public after using it myself for a couple of months. There are thousands of other themes out there, so why should Nord not also please others. The question where the project should live was answered quickly because the answer was of course “GitHub“.

Initial Project Features And Structure #

The main “home“ of Nord was my personal server where it lived in a Git repository that consisted of the core features like the Sass ¹, Less CSS ² and CSS variable ³ ⁴ stylesheets. Up to today these are and will remain part of the core of Nord since such features are the way how color palettes can be implemented in a distributable format. The documentation was and is also still included in the code itself using the KSS (Knyle Style SHeets) project. At that time I did not want to create a large documentation, so the “human-readable“ version of this documentation was generated from the KSS code documentation as well as via SassDoc, a documentation generator for Sass. Also part of the core are the native color swatches for various applications ⁵ ⁶ ⁷ ⁸ ⁹ which are also a part of the main repository to this day. Assets like the logo and palette overview SVG were created before migrating to the new public GitHub repository so that the project starts with a good visual and appealing presence.

Next up I started to plan how to organize the already existing application ports and I decided to simply recreate the same structure like on my personal server: a dedicated repository per port to modularize and separate the purpose of these ports as good as possible. The main repository included links and image banners to these repositories for a good overview of available ports.

The Beginning Of Port Projects #

At the time my set of tools was a little different compared to today so the first port projects were for the GNOME Terminal, Atom (UI & syntax) as well as the fantastic products from JetBrains. With the scope in mind to build port projects for my own tech & tool stack I also started to create other ports, but did not publish them until I was satisfied with the outcome during the dogfooding phase. I knew that I want to adapt Nord to my whole setup which was the motivation to create more ports. After several months there were round about 14 ports with 6 of them being publicly available.

Public Awareness #

With the publication of some ports to official package/plugin/extension registries of the corresponding platforms, e.g. the Atom theme registry, the distribution not only allowed myself to use and update the ports easily but has now made it even easier for others to discover and use it too. After a while some GitHub repositories of the ports started to get their first “stars“ which is more or less a meaningless sign that others either really like the project or want to “bookmark“ it. Nevertheless it showed that I was not alone with my taste in terms of the style of my applications and after a while the first issues/PRs started to come in.

Nord also started to attract attention at places where I would not have expected it at first: /r/unixporn, the famous subreddit for Linux ricing. More and more posts started to showcase Nord and others replied with positive feedback and ideas for improvements and expansion. To see that the own project is so well received increased my desire to keep pushing the project forward.

More Ports, More Time #

With the increasing public interest, there was also an increasing expenditure of time. On one side this was due to my personal principles of always meet a good level of quality for my projects but also the fact that requests, either for new features or improvements, and support for users of the ports took up more and more time.
While ports for terminals usually only rarely need changes after the initial creation other ports must evolve with the target application or platform. Especially the ports for Atom took a lot of development time because Atom‘s theming API was not tied to a encapsulated feature set but allowed developers to freely style and modify every element of the application via CSS. In the be beginning adding support for the packages I used was the main goal, but later on requests for various popular or new packages were the order of the day. The port for JetBrains products, initially named nord-intellij-idea-syntax and renamed later on to clarify the scope, was also evolving quickly and the port started to consume more time.

All in all, this was still within limits, but with the increasing number of new projects, the free time that these projects took up became more and more.

Beyond But Also Within Personal Use #

With increasing popularity of Nord in different bubbles of the www the requests for new ports and the expansion of existing ones got beyond my initial goal of building things in the scope of my personal need. That was not a bad thing at all and it enabled me to learn new and interesting things, but again the effort grew exponentially while the allocation of my free time for other projects was further reduced.

During this time new ports for Tilix, initially named “Terminix“ and renamed to “Tilix“ later on, and iTerm2 were born which are now part of my personal tool stack too or even replaced some other applications I used before (e.g. “Tilix“ which replaced “GNOME Terminal“ as my main Linux based terminal for modern GTK environments). With the rise of Visual Studio Code, the emergence of a new port was not long away and it also replaced Atom as my main text editor. Many other ports followed such as Nord for Vim, Emacs and Hyper Terminal as a result of frequent inquiries and the fact that some of these applications are well-known and established.

Today‘s Scope #

At the time of writing this Nord officially has 35+ port projects with currently 130+ tracked open requests for new ports, not counting in the ones of various different platforms and communications channels like the official /r/nordtheme subreddit, chats, emails and my personal notes. Nord is also integrated and shipped as theme in many commercial and open source application so that users can enable it out-of-the-box without the need to install it separately. I also stopped trying to keep track of the huge amount of community creations like “unofficial“ ports for other applications and platforms, custom projects with Nord as “built-in“ theme or even projects that are build around Nord, not to mention the thousand (GitHub) repository forks or maybe private copies of Nord and its ports with the intention to customize it for personal preferences. In addition, Nord is known and used in a wide variety of areas, from news pages about technic topics to personal website/homepages or on “real world“ products like computer hardware (e.g. custom mechanical keyboards), music instruments or desktop accessories/equipment like lamps and desk mats.
Nord has grown as big as I could not have imagined and apparently that is far from the end. It even won competitions like for the most-loved JetBrains theme plugin back in 2019.

I always tried to keep things as close to the users as possible by building a community where people love to use and contribute to Nord. The official /r/nordtheme subreddit with almost over 3500 members, at the time of writing this, is an active place for users to talk about Nord, present own creations or ask questions. Chat platforms like the, now both discontinued, official Nord team on Keybase and, still read-only but also discontinued, space on Spectrum are places that were great to get in touch with others about Nord in real-time, find help or simply hang out. More information about the new chat platforms are written down in the “Real-Time Communication — Welcome To Matrix & Discord“ section further below.

Nord and all of its ports has multiple millions of downloads, views and interactions across various platforms and the number is increasing every day. Every time I recall this fact it seems surreal to me.
I never assumed that Nord would take on such proportions and forms such a large community and ecosystem around itself. But here, too, you have to look at the other side of the coin that such a project entails, which I will go into in more detail in the next few sections.

Behind The Scenes #

In the part about the history of Nord I tried to describe the process of creation and today‘s ecosystem but who exactly “am I“ and what is this “Arctic Ice Studio“? The next sections going more into detail about the human aspects behind Nord and how all of this is related to the “studio“ with the “cold“ name.

Identity & Branding #

Right from day one after deciding to make Nord an open source project it was also clear to me that, based on the project structure with multiple repositories, I want Nord to be presented by a matching branding. This should also ensure that the scope becomes clear and allow users to easily recognize and be able to assign it to Nord.
The result was Arctic Ice Studio, a name that reflects the nordic style and implies a organized structure instead of a personal single repository. The fact that the newly created GitHub account is a “normal“ (person) account will play a role in the section about the branding and its drawbacks below and explains the disadvantages.

The (Single) Human #

It is completely understandable and also my own fault that there is often confusion when people think there is a kind of company behind Arctic Ice Studio which unfortunately often sets certain expectations. However, the truth is that I, Sven Greb, am the only person.
I have had to clarify the fact many times and in retrospect it was probably a mistake to let Nord drive under this flag.

Anyway, I would like to briefly introduce myself here in order to have this topic written down a bit more centrally.
My name is Sven (maybe because my name origin is from the north is the reason for my preference for the arctic nature?), I am currently 30 years old and I was born and live in Germany. I‘m a software (solution) engineer with a focus on “DevOps“, or call it “fullstack“ or whatever is currently trending, working 100% remotely full-time for a German company. I think that‘s enough as a short and crisp summary, after all, this should not sound too much like a speed-dating or doctor introduction 😁

At this point, however, I would like to make it clear once again that of course this only relates to the core “team“ and the project would not be what it is today without the many contributors.

Branding And Its Drawbacks #

For a long time I was satisfied with the path I chose with the Arctic Ice Studio branding, but over time the disadvantages unfortunately became clear. At the time of creation, GitHub “Organization“ accounts have been available for a longer time, but I decided back then to make a normal account to allow users to follow it for updates and ensure that Git commits can be easily recognized through the committer name arcticicestudio and email development@arcticicestudio.com. And yes, I bought the arcticicestudio.com domain to also make the branding more clear and also allow me to separate Nord from other projects. The problem that crystallized over time, however, was that many users apparently thought that a company was behind it and then made inquiries and claims at this level. I tried again and again to clarify this misunderstanding, but over time it became more and more repetitive and in the end it didn‘t help either.

Why didn‘t I convert the normal “user“ account to an organization? The answer to this are the limitations and losses that would result from this:

All commits of the arcticicestudio user account would not be linked to it anymore, resulting in “ghost“ commits without a valid committer. Even though the commits itself of course will remain intact, it is a loss of project development history.
In contrast to GitHub user accounts, people can not follow a GitHub organization which means that all users who currently follow the arcticicestudio user account would be “lost“, resulting in missing update notifications and community interconnections.
→ As of March 2022 GitHub finally introduced the new feature that allows to not only follow person account but organizations too! 🎉
Therefore this point is not 100% relevant anymore, but it still means that all users who currently follow the arcticicestudio user account must start to follow follow the new nordtheme (and optionally nordtheme-community) organization(s) to receive notifications and updates in the future.
2.1. The same also applies the other way around: the arcticicestudio user account would lose all the people it is following at the moment, also resulting in important connections to the open source community.
All GitHub stars and lists of the arcticicestudio user account would be gone too since organizations can not have stars. This would also be a loss in important resources and links the open source ecosystem.

With all these disadvantages I recently decided to create the new GitHub organizations nordtheme and nordtheme-community instead, also just to make sure that it won‘t be taken by name hoarders or someone who want to fake an official Nord account. This way I could move Nord repositories to this organizations instead, leaving the arcticicestudio account information and data intact. Organizations are the perfect way to ensure that all repositories and data stored in it is scoped to a single project which makes the goal and purpose of it much clearer to the outside world. With my in-person account svengreb as the main organization owner it would also be clear who is behind Nord and new commits would be linked to it.

Next to this, organizations also provide tons of useful features for, obviously, (business) organizations and larger projects and every day I regret the decision not to have built Nord as such from the beginning, but not anymore as of today…
In the “Nord‘s New Home On GitHub“ section below I detail what major changes are coming and how Nord on GitHub, as well as the documentation, will be moving to a new home.

To finally get a better representation of the human behind Nord and have a clear representation for sponsors as well as my other open source projects and contributions, the future plan sections below contains details about the retirement of Arctic Ice Studio as Nord brand and the goal to put more focus on the human behind it.

Work-Life Balance #

Or to put it more clearly: time management is hard.
To roll this part up a little from the beginning, you have to know that I created Nord before the end of my studies/training. However, most people tend to have more free time compared to the phase in which “the seriousness of life“ begins. I was able to invest more time in Nord without having to neglect other topics. After starting to work full-time, however, time management and the “work-life balance“ is clearly gaining in importance.

This topic got more and more attention over the years which is absolutely justified. I would like to go into a little more detail in the next few sections about how things changed when it comes to the available free time and the decision how to spend it.

The Desire To Be “Doctor Who“ #

Even if “Doctor Who“ does not come from my time (pun intended), it is a good example of how one would like to solve the time problem. Traveling through time or pausing it would be the perfect solution for many things, but it will probably remain fiction forever (maybe better that way?).

Anyway, finding time, and on some days also motivation, to work on Nord has changed over the past few months. While the initial phase of Nord, where the development of ports for well-known applications and platforms was on the agenda, was quite easy, over time it became increasingly difficult to find time to learn about the required knowledge for new ports. With the increasing popularity, the need for user support also increased and I had set myself the goal of always trying to support as far as my possibilities allow and as far as it is appropriate. Unfortunately, this is of course also at the expense of further development. Even if others helped more often in certain topics and I could rely on the community to help each other, in 80% of the cases I am still the only one.
The publication of frequently requested ports for applications that I never use myself, and whose concepts I only learned through time-consuming research, became more and more difficult over time and often caused frustration.

All of this was now also characterized by less time due to working life and the fact that you also want to live outside the digital world. In these moments the urge to manipulate time grew and the search for a solution, or at least an improvement, of the problem became more and more important.
The measures for solving or improving some of these pain points can be found below in the section about the future plans, especially the one about the focus of development, with details on how and why things will change.

Working in Public #

One important reason for stress is the fact that all the work in done in public. If I had built Nord on my own in a “private space“, such symptoms would never have appeared. I do not regret it for a second because I breath open source, but I have a need to convey to people what open source entails. Going deep into the materia would mean that I‘d had to start a long-time research and hammer in content for a whole book in this section, but luckily someone else did it and she did an absolute fantastic job.

“Working in Public: The Making and Maintenance of Open Source Software“ by Nadia Eghbal (@nayafia) is, in my opinion, a masterpiece and I felt like she‘s streaming my thoughts and experiences into the book I‘m holding in my hands right now. Almost all the scenarios, pattern and the usual behaviors and phenomena that occur have been written and explained in detail perfectly.
I wanted give back some love, appreciation and feedback for this book in an explicit section instead of only mention it somewhere in between. The book is an absolute recommendation and, in my opinion, almost a basic reading for everyone who wants to dive deep into open source.

I bought this book due to the interest in open source, but I did not expect to take away that many learnings from it, e.g. a lot of background knowledge and comparisons to “real-world“ concepts, where most of them are not related to any technical topic at all but mainly concepts and ways to think and organize the pile of work as a maintainer and project leader. An interesting learning is the division of projects into specific types where Nord can categorized as a “Stadium“:

Stadiums are projects defined by high user growth and low contributor growth. In the same way that lots of people at a concert focus on one or a few performers on the main stage, the fast-growing userbase of a stadium-style project depends on one or a few maintainers.
Due to their low contributor growth, the social structure of these projects tends to be more centralized (one-to-many interactions), so the primary bottleneck to getting work done (merging PRs, responding to issues, etc.) is maintainer attention.

This can be seen as good and a little bit bad at the same time. It it interesting to see that really large projects like Babel are also assigned to this type and it works out quite well, but it also confirms my feelings and experiences after Nord started to go beyond my personal use.
The fact that is also very interesting here is that this project type is very common for color palette/theme projects, or projects that are related to any kind of “design“ work at all!
This can be explained quite easily: transfer, e.g. through documentation, a visual imagination and “artificial imagination“ is almost impossible.
it is possible to write about specific concepts, e.g. the theory of colors, but teaching someone in a “static“ way how to apply them in a free artistic way is not possible. Even though I don't like Google‘s Material Design at all, their documentation is fantastic when it comes to “static“ explanations, but again this will not help someone to contribute to design related project if you don‘t understand the art style of the project.

I though about going a little bit more into detail about all my learnings, and my notes I took that result in some future tasks, but this would go beyond the size goal here so I‘ll write a dedicated (blog) post in the future about the key facts and how they relate to Nord.

The Ecosystem #

Somehow it still sounds a bit strange to me, and possibly also from the outside, when you consider that Nord is “just“ a color theme, but given the size the project has grown to, you can call it a digital ecosystem. The diversity of the ports extends over many areas of different technologies and the community extends the scope all by itself to more and more areas. The communication is spread across many platforms, starting from the official /r/nordtheme subreddit to various forums, blogs and websites about technical news.
In the next few sections I would like to go into a little more detail about what this system currently looks like.

Nord‘s (No Longer So) New Home #

Basically we cannot speak of “new“ here as the official Nord website has been available for more than 2 years now. Unfortunately there has always been no time to write a reasonable blog post, but this was also due to the fact that the implementation of the blog itself has not yet been fully completed and its use would therefore only have been possible to a limited extent. This will also change in 2023, but more about this in the section about the future plans for the migration completion to the new home and how the blog will be filled with life.

The plan and reason for the website was to create a “single-source-of-truth“ for information, assets and resources of Nord. Each port was mostly self-contained regarding its source and documentation. However, there was always a correlation to the main project, the color palette itself, that made it necessary to link between repositories or even include some assets of these.
On the other hand, the main repository needed to keep references to all of the ports making it time consuming to adapt to changes like documentations. Many port repositories included both the code and documentation sources and even hosted them at the same time e.g. some had dedicated GitHub Pages.
Like mentioned above the blog was and is still meant to be a clear communication channel to publish information and news about Nord. The distributed platforms like Mastodon, Twitter and Reddit as well as the real-time communication channels like Matrix or Discord should and will continue to play a major role, but a central point for linking is always the best solution in the end. The blog also allows to create extensive and customized content instead of being limited to the possibilities of respective platforms and ensures that the information is persisted without any dependencies to external services.

A dedicated website also comes with a lot more advantages and lifts the restrictions that you have when you can only use Markdown to structure content. It allows to design and “let off steam creatively“ instead of being limited to a small frame within another website. Creating a home with a modern and elegant style to represent Nord helped a lot to discover and play around with my own design philosophies and “round off corners“ where some Nord concepts did not fit for a comprehensive project.

The design, plan and implementation of the website took almost one year and was developed while still trying to keep Nord in active development. It was also a playground to use a lot of my tech stack and build something that corresponds to my ideas and of course served the purpose to reduce the maintenance overhead through a bundled channel of information. All of today‘s great ways to automate and simplify deployment processes made it kind of a breeze to get get things up and up-to-date within minutes.
I learned a lot during this time and of course the development is an ongoing process. Like all other Nord repositories the whole website and documentation has been made open source after the initial launch so that the community can work together and learn from it too.

The Wide Variety Of /r/nordtheme #

One way for users to show and share their own or link to creations of others is the official /r/nordtheme subreddit. At the time of writing this, it has over 3600 members which is a bit crazy when it‘s “only“ about a single color theme. The content and discussions can not be more different and ranges from “I‘ve created a new port“ to “My office workstation now has a Nord-themed desk“ or “I‘ve created some Nord-inspired art“. Often just questions are asked too which are then answered by the community, no matter how “simple“ they may seem. Newcomers are always treated kindly and should never feel emaciated.
All in all, it‘s a good platform for Nord and that‘s the way how it should stay in the future.

Real-Time Conversations… #

Even though platforms like Reddit are a great a way to share content and discuss in a more or less asynchronous way if you do not count the built-in, but rather rudimentary chat function. That is the reason why I also wanted to provide a way for real-time conversation through online chat(s).
One of the selection criteria was that it should be a free and user privacy orientated platform which should be based on open source software and protocols to prevent vendor lock-in. At the time of evaluation, the choice fell on Spectrum ¹⁰ and Keybase which were both build on top of their own open source frameworks and the protection of users‘ privacy is, sadly in the case of Keybase “was“, one of their development principles.

Even though the Nord Keybase team is quite small and the daily activity is not that frequent, users of the platform can talk about Nord and all of their other favorite communities through a single application. It is also a way to make new users aware of Keybase as it is not so well-known for its communication functions.

The Nord Spectrum community on the other hand was a little more active, but to be honest you have to say that Spectrum had “Chat“ in its name, but the structure of the content was more like /r/nordtheme and and rather less a real-time chat. Anyway, the idea behind Spectrum was good, but there were things in the implementation and overall concept that could not be easily changed afterwards and the creators had plans to continue their vision in a different way. This is why they announced that Spectrum will be sunset on August 24, 2021, but maintained in read-only mode to prevent 404s and the loss of a little internet history. However, this meant that this platform was no longer available for Nord and only the /r/nordtheme subreddit was left for the type of content.
Spectrum was acquired by GitHub and they hired the authors and core developers in order to make Spectrum part of GitHub itself, but later on they decided to only take the core idea and built the fantastic GitHub “Discussions“ instead. Today the https://spectrum.chat domain also redirects to the GitHub “Discussions“ feature page.
The successor is better is all aspects and something that many GitHub users have been hoping for a long time, including me, of course.

…And How They Will Evolve #

With Spectrum being read-only and Keybase being a relatively small community, and not that optimal platform for real-time communication, I was not really satisfied with how I‘d like it to be for Nord. During the yearly “GitHub Satellite“ event they announced the new “Discussions“ ¹¹ feature, a kind of forum that lives right in a repository. This way communication happens in harmony with the actual code and all of its development history. The seamless integration into the existing functions such as issues and pull requests finally gives project maintainers and teams the option of fine-grained control of the various types of community interaction.

With this fantastic upcoming platform in mind I started to plan how it will finally change the way how the Nord community can be connected.
The elimination of a platform like Spectrum for “thread-based“ chat content by its successor will be intercepted by the new GitHub “Discussions“ feature which will also make it possible, e.g. interactive votes and polls ¹² without simple ways to “cheat“.

The other open point, however, was still the platforms for “real“ real-time communication, basically a pure online chat. Because I never saw Keybase as a full-fledged solution I also considered proprietary (semi-commercial) but popular platforms like Discord and Slack. The latter was quickly rejected because the concept of Slack for inviting users is an absolute disaster and the possibilities of the free usage plan are terribly limited.
Even though the way how Discord manages user access and invitations is not great too and resembles the one on Slack, in the end it is a much more flexible platform that is also popular with many open source projects and is supported and promoted by Discord. In the beginning, however, I put both ideas aside to evaluate them later when GitHub Discussions has been established for Nord.
The perfect solution from my point of view, however, was Matrix which was only blocked by the fact that a dedicated server would be required if an own instance should be the way for Nord and whose financing I still do not see on the side of my private budget. The Matrix project is the communication protocol of the future and is used in a lot of areas around the world, from government agencies to technology conferences (e.g. [FOSDEM 2022 & 2023) and countless open source projects. Recently Gitter, a chat and networking platform that is used quite often for small to medium sized open source projects, announced the full migration to Matrix and usage of the fantastic Elements clients instead of a custom protocol and client.
With ones of Matrix‘s flagship features named “bridges“ it is possible to exchange data and messages with other platforms, using its open standard specification, including a lot of proprietary ones like Discord and Slack. This would be the perfect solution for Nord as it would seamlessly synchronize chats across the different platforms which basically makes it a large, central community without having to bind the individual users to a certain application and instead letting them use their favorite one.

I do not really want to go into more details in this section, but I think you can guess what it will lead to. Therefore, more details are described in the section about the future for the community home below, like the new Github “Discussions“ for Nord and the upcoming Matrix & Discord platforms, as it is more appropriate to the higher-level “future plans“ topic.

The State Of Things #

Now that I have walked a little through the history of Nord and who is behind it, I would like to go into the current status of various aspects in the project.

Keep Things Up To Date #

Building an open source project means that it requires, to a certain degree, maintenance in order to be healthy. Of course, this also applies to the ports of Nord where some are kind of “feature-frozen“ after the initial release, although these are mostly just the ports for shell terminals since they only define the values for the available colors and sometimes a few other little attributes, e.g. the color for the cursor and selections. Most of the other ports, on the other hand, require continuous attention because the target application continues to develop too.
Some good examples are the ports for Visual Studio Code and JetBrains products where both upstreams publish scheduled updates that often come with many changes. The problem here is that of course it‘s not just these three ports but the ones that I don‘t always use myself. Some of them are not up-to-date because I‘m not that confident and familiar with it, but external contributions are also rare.

The required adaptions are often different, but are similar in common points: they require time and research what exactly changed, if and how it affects the port and time to plan and prepare the next steps. Some might say that only changes to theme APIs must be considered but forget how much time and effort it takes to find and understand them first.
The first thing you have to do is to know when updates for upstreams have been published which is quite easy for my own tool stack, but harder when it comes to community requested ports. Afterwards you have to read the release notes/changelog in detail and note down changes that could be relevant. Having such a documentation is also something that can not be taken for granted, or when something similar exists they are are hard to find or must be put together from different sources on your own. The next steps are to try out the changes on my own and start to prototype how the changes can be adapted for the port. Finally, the adjustments for the port must be documented and the implementation persisted, following the whole process to get it into the code base.

Other ports like the one for Vim (including the upcoming one for Neovim) and Emacs doesn‘t require updates due to upstream changes that often but mostly through requests, e.g. support or changes for third-party plugins & packages, compatibility improvements & additions and many more. The same or sometimes more effort is required in there like in the case of the ports mentioned in the paragraph above. This is because for requests like the support of new third-party plugins or packages I not only have to regain knowledge about these but also often have to somehow create a local test environment in order to implement the changes. This requirement is also not only valid for new features but contributions where pull requests need code review as well as local testing for visual validation. Learning about the change, how it works, what actually changed and how to finally recreate and see it locally often costs hours, even when the code change is minimal.

No matter what type of port is changed, it all costs time and effort that has to be planned in order to use the time efficiently.

Help Users To Make Thinks Working #

Even if a well-maintained project is “half the rent“, there will still be occasional problems on the part of the user in the end. That is normal and part of maintenance but the time and total effort must always be taken into account.
For Nord I try to manage this topic through dedicated “Support“ project boards that live in each port repository, e.g. the more frequented ones of Nord Vim or Nord Visual Studio Code. This way I have an overview of open tickets and can use it to search through closed ones to use them as reference in same case scenarios. More details about how this topic will be organized in the future are written down in the section about the central project planning and issue management further down. With the announcement of “discussions form templates“ the “time to first useful support reply“ will be even easier because the templates will help users to help supporters to get the required information in the first place.

Overall, the topic of Nord user support (and also in general) is unfortunately often something that is not perceived directly from outside, but it is actually the part that (currently) takes up most of my free time that I can spend on Nord.
The same conditions like in the section above apply here too:

Ensure that all required information are provided, otherwise it will be hard or even impossible for me to analyze and possibly reproduce problems.
Take time to understand what exactly went from and try to identify “quick wins“, e.g. I‘am familiar with common mistakes users make and can spot some in the first few seconds or minutes. If this is not the case, take the time to understand the problem.
If the problem is something that can be reproduced I need to create an encapsuled local test environment and find a way to get the same data like the ones provided by the user.
If it can be reproduced and resolved I try to reply with as many details as possible to the user so that they can also imitate and solve it on their side.
4.1. If the problem can not be reproduced or is too complex due to single use cases I try to discuss how it can be solved on their side by trying to guide through some possible solutions and wait to see what the result was.
In the best case scenario, the problem is solved or the question answered and the ticket can be closed. I often try to note down information about unusual cases so that the project documentation can be extended or improved or maybe even create a ticket for a code change because the reported problem was indeed related to it and nothing only scoped to the users system.

This process is time-consuming, but necessary in order to be able to support users to the best of their knowledge and belief and to ensure that the project continues to be of good quality over time.

Push Things Through Quality Gates #

As the number of users of a project increases, so does the responsibility of the developers. In summary, this relates to the quality, stability and compatibility that the project has set as its goal since the beginning. This sets a certain expectation that users have of the project and if one of the two worsens it will attract attention from the user and also cause frustration on the part of the developers and maintainers.

With some things you could say that certain changes in the Nord project take too long, but there is much more to it than it seems. Some users don‘t understand that “simply change and merge this“ is not an option for projects with a large user base. Unfortunately, they often have no feeling for and understanding of what it means to find solutions that not only correspond to their own interests and preferences but also to the overarching goals of Nord. For example, pull requests in repositories, often without creating a ticket beforehand to discuss possible changes in advance, where the foreground color of a specific kind of syntax element is changed just to make it look like in a way the author likes it, are more a waste of time for both the creator and maintainers. Even though it is hard or even impossible to document a specific creative idea and its way of thinking I‘ve tried as good as I can to do so by describing the meaning and use of colors in form of the official color & palette documentations. With this in mind, changes to Nord and its ports can be justified and are the (soft) guideline for development. Change requests and discussions without a basis on the concept and goals of Nord are therefore nothing but obstacles in the way of a smooth project development.

The attention to the quality, stability and compatibility is important during the development process of Nord, but this also has side effects that unfortunately many do not understand. For any change it must be tried to not break the setup of any user if it can be prevented in any way. Even though most Nord ports stay in major version 0.y.z as long as necessary, which means that anything may change at any time and it should not be considered stable, I try to keep the breaking changes as low as possible. The development process consists of multiple steps such as…

…research on which facts the change is based, e.g. reading and learning about new features or improvements from upstream projects of Nord ports to understand how Nord need to adapt them.
…reviewing and collaborating on the actual code to ensure that it matches the project style and quality and is maintainable in a long term for existing and new maintainers and contributors.
…testing the changes locally, and if appropriate also in automated environments (CI), to ensure that they are working as intended for supported upstream application versions. Building projects that are mostly “visual“ also require a lot of manual testing since automated tests are not made to validate authenticity and creative appearance.
…creating assets and documentations for the project development history, e.g. the changelog for release versions.
…going through the “after-merge“ process such a managing metadata of GitHub issues and pull requests, sort tickets into project boards and ensure they are included in the corresponding release milestone(s).

All in all, there is more behind changes than outsiders can directly see and therefore everyone should understand the maintainers. This also applies in general to the “real world“ and other things outside of project development.

Quality Comes With Time #

I would say of myself that I am a semi-perfectionist and I often approach things with “do it right or leave it“. I also know that perfectionism can sometimes be limiting, but the opposite of that has much more glorifying effects in most cases. For one or the other, who are influenced by today‘s fast-paced society and where “patience“ does not appear in the vocabulary, and thinks that this way of thinking may seem too “slow“, but if you only work half-heartedly on a project and “knit it with a hot needle“ you will quickly notice how the complexity and the effort shoots into the bottomless. If you take the time to think something through well beforehand, you will end up with a result that can be adjusted much better later or even does not have to be adjusted at all.

One of the other reasons why projects fail is the usage of deadlines/time limits regardless of whether in professional areas or open source development. I can say from my own experience that things will go wrong fatally as soon as any foolish talkers believe that a product is created with a snap of a finger and sadly these people actually have expressive power.
Following the “things are done when they are done“ principle should always be high up and those who follow this principle are often those whose projects are ultimately successful. Projects under time pressure will burst.

Quality Is In The Details #

With the aim of giving a project a quality standard, even the smallest things count that are often only perceived as details. In the case of Nord, in addition to the tasks already described above, these are also things like e.g. writing documentations that still make sense after reading it through the second time and help to understand the project even after a long period of time.

A good example is the creation of release notes and changelogs. Releasing a new version of a port comes with effort overhead which consists of more than just building the (binary) artifact itself but also a research of what has been achieved since the last release and documentation of these changed. This is important for both, the maintainers as well as the users, as it records the progress of the project and gives an overview of how the project has changed and what users can expect from new versions.
I have also made up my mind to maintain a certain quality standard when documenting versions that is somewhat different to other projects which often use automatically generated release notes and changelogs that arise from the Git commit history. This often comes with the major disadvantage that many developers do not write detailed information in their Git commits or that it simply goes into too much technical detail. Doing so is completely correct and okay for Git commits, but when it comes to release notes, the way of writing should be designed more for humans and contain more details about certain changes, possibly also small instructions on how these new features or improvements can be used or how to adapt to (breaking) changes. Overall, release notes and changelogs should read more like a running text instead of a banal list of Git commits. For my projects the way is, and has always been, to ensure that other resources like GitHub issues and pull requests already include all information in a “human-readable“ form so that it can be copied over to release notes and changelogs later on, only requiring to adjust the way how these information are structured and presented.
For projects that have a lot to do with visualized content, as in this case also Nord, graphic content in these documentations are important in order to make it clearer to the user what has changed, which in many cases is not possible with a purely textual description. A good visual style and presentation is also much more appealing and ensures that reading release notes and changelog is actually more fun for users instead of just fulfilling the purpose of receiving information about changes.

Another aspect is the build & release processes which is completely different from port to port, but in order to not go into too much depth in this section, more information is described in the “Tools Are Key“ section with details about what is planned to simplify and/or automate these tasks.

Public “Early Access“ #

There have often been requests in my direction that I should make projects, that are still in the early development phase, public as soon as possible. My answer to this is that the “early access“ concept is very controversial and in 90% of cases where it is used it causes flops as important aspects such as quality and compatibility are completely disregarded. One of the best negative examples is the usage on the gaming platform Steam where the games pissed off all potential players even before they were actually published because a completely unusable product is presented and interest disappears after a short time. After that, the game disappears into the great maw of the innumerable games and, even if it turns out to be one of the best developed games, won‘t be touched after the release.

This is why Nord does not make use of this concept and instead ensures that the important aspect are always part of the development process. New ports will be published as soon as they are in a state for the initial version and not a unstable alpha/beta.

Sponsoring #

If one imagines that open source projects disappear from this planet for a few minutes, ~95% of our modern world would no longer function within a few seconds. For most people it is not visible because their favorite products, which they use day in, day out, simply work, but without open source they would basically never have existed. Without open source ~90% of all servers would simply be gone because Linux is probably the best example of open source and is the reason why there are hundreds of thousands of other projects at all.
However, all open source projects have one and the same problem: they are all perceived as self-evident and the people behind them, who often spend a large part of their free time on it or even sacrifice it, are in most cases not seen or appreciated for their efforts. Their “products“ can simply be used in other open source or proprietary/commercial products without having to pay a penny but even earning some. Some will now say “But they made it public on purpose“ and the simple response to that is “Yes, and without them you would not even be able to write this comment on a digital medium or even send it because the device and the platform would not exist“. I think you understood my point of view.

All of this leads to a topic which fortunately has finally gained in importance in the last few years and which should be taken for granted in the future: sponsoring and appreciation of the humans who build open source projects you and thousands of other depend on. Open source is an integral element of every technic and digital product company and should act responsibly towards open source maintainers. GitHub is the golden standard platform for open source and is also the best example of how to approach this problem through their awesome sponsoring features.

Invest in the open source projects you depend on. Contributors are working behind the scenes to make open source better for everyone — give them the help and recognition they deserve.

In the next sections I will go into several areas to what extent the topic plays a role for Nord and how I would like to approach it.

How I Feel About Sponsorship #

I think the introductory words under the “Sponsoring“ main section above shows my opinion on the role of sponsoring in the open source area, but I would like to explain some important aspects of it regarding my projects and open source work. There are dozens of important open source projects like the Linux Kernel, containerization technologies like Kubernetes and all these millions of small libraries and packages that are part of the foundation of great creations. In my opinion something like a color theme is not that important and must therefore play another role for the distribution of sponsorships. This is something that I would like to make clear and that is why I see more important projects in advance to get financial support and attention. Please don‘t get me wrong here — that doesn‘t mean that small projects don‘t deserve it, but I‘ve often seen that quite “useless“ or “trendy“ projects have more sponsors while essential projects that really need it go empty-handed.

My opinion in the case of Nord is that I never thought that it would grow to this size and that sponsorship would be relevant. Of course I‘m happy about every help and appreciation I get for my work on Nord, on the other hand I always had a little feeling that one was influenced by it and felt a bit “in the debt“. Even before the topic became more important, I was often asked whether and how one could provide financial support, and at the time I was hesitant about whether I would like that. At that time the ways and possibilities to receive this support were still quite limited and you had to resort to methods like simple transfers, e.g. via PayPal. Larger platforms specializing in support such as Open Collective either did not yet exist or the profit share was so high that it was not worth it for small sums of money.
In addition, I basically wanted full transparency for this support, firstly to show it to the outside world and secondly to highlight and thank everyone who supports Nord financially. With the transfer methods at the time, this was difficult or even impossible. Luckily the whole topic gained relevance and publicity and great features like GitHub Sponsors were invented which eliminated most worries and problems.

How You Can Become A Sponsor #

Like mentioned above, becoming a GitHub Sponsor is the way I‘d recommend everyone since it provides full transparency and is secure for both sides the sender and receiver regardless if it is a single developer or a whole organization. I think many now know the way how it works and how you can tell whether an account is configured for it, so I will not go into further details here and only refer to the (as always) good and detailed GitHub documentations.

What is perhaps not so well known, however, is that my “sponsor profile“ is available since the beta version of this feature and the short summary on the page contains more information about me and my open source work, from Nord to a lot of other projects. There are also other ways, e.g. one-time payments via PayPal, but a GitHub sponsorship is and remains the best way to support Nord and the whole open source community. Thanks to the continuous development of GitHub features it is also possible to define a custom amounts or simply do one-time donations if you don‘t want to pay on a per month basis. This functionality almost eliminates the need for any other method since it allows to decide whether to sponsor in intervals or simply boost your favorite projects just only one-time. There are also small benefits for sponsors based on the amount, e.g. prioritization of a request in ports or early-access to private repositories of upcoming Nord ports or sub-projects. Every sponsor, regardless of the amount, will get a “Sponsor“ badge on their GitHub profile to show the support for the open source community to the outside world. Or simply become a anonymous sponsor if you‘d like to support my work without being recognized and protect your privacy.

I am somewhat critical of the question regarding sponsoring via “cryptocurrency“ because I do not really want to support this environmentally polluting and quite useless technology in any way. Therefore I do not want to offer this possibility at the moment and if necessary introduce it after careful consideration, and only if it is necessary in any way because GitHub sponsorships should be sufficient in principle.

As a small summary here is a list of the possibilities and platforms how you can support Nord:

GitHub Sponsor — become a supporter through a monthly donation with a pre-defined tier, a custom amount or simply do a one-time donation.
PayPal — if you would like to simply say “Thank you!“ in a less “fancy“ way.

Where Your Help Is Used #

Sponsoring is a great way to support the humans behind your favorite projects and in various cases it is also the way how some of them pay their daily bills by doing open source as their full time job. For all others who do this in their free time, donations and sponsoring are the ways to say “Thank you“ which make it easier to enjoy things in the “real world“ or even make it possible to do some of them. It shows appreciation for work on a “product“ that is “free“ for everyone while often being an essential part of a workflow or life style. For me personally it means that I can get keep enjoying my favorite types of coffee, get gifts for my loved ones or buy small equipment for my sport.

Apart from that, I would like to put some of the donations back into Nord to make it easier to maintain it, which in the end means that I gain more free time. So it‘s a win-win situation for everyone, the community, the developers and Nord itself.
I won‘t go into detail in this section but refer to the section about building a dedicated-infrastructure for Nord and the community which describes exactly what is planned and how donations and sponsors do their part.

The Future Plans #

First of all, I would like to say that everything that comes in the next sections is a rough plan, but not “carved in stone“ and things can change. I have had many points on my personal notes for a long time and I would like to finally bring it into a planned process in order to start working and finish them. Most of them emerged over time when the need arose to standardize and simplify certain processes and tasks. The next sections will go into more detail about what exactly is planned and how it will be scheduled while actual resources, in form of visualized roadmap(s) and tasklists, will provide a complete overview.

Development Focus #

The time spent on the ports still makes up the majority of the day-to-day work and is therefore very high on the list of things that need to be optimized. While some processes have already been adjusted more on my part in order to save time, there are many more that slow down progress. In the next subsections I would therefore like to introduce what and how things will change in terms of pure development.

More Fluid And Automated Workflows #

The title may sound a bit general, but it basically means that processes such as the triaging and processing of new issues and pull requests could be made in batches instead of “drop-by-drop“. In the past few years, I have often tried to work through them from one at a time, but I came across the well-known problem that it is more difficult to get into a topic when you have previously been busy with something completely different. This tearing away from concentration is the problem of why you should eliminate (in 90% of the cases absolutely unnecessary) appointments from professional areas such as the IT industry. The quick change of contexts works for CPUs but it is an absolute productivity killer for humans.

The planned changes and improvements for this topic are therefore to…

…find day(s) on which new tasks can be worked on in one go — the day(s) must not be fixed and should be flexibly adapted to other priorities.
…create a more stable process of how these tasks can be prioritized and arranged in a time frame — it is normal that some tasks are limited to a certain period of time or are more urgent than others, e.g. when an upstream application introduced breaking changes in a new version and a Nord port must adapt them, including possible backwards-compatibility. A prioritization ensures that Nord can still be used and that maintains its self-imposed quality standard.
…develop a way of documenting this process and presenting it to the outside world to give users an overview of progresses — GitHub‘s “issues“ features such as “Projects Boards“ are the perfect way to keep it near to the project itself while allowing to integrate it natively in other features. These resources will form the single-source-of-truth for me as maintainer as well as users. All details about this topic can be found in the section about the central project planning and issue management further down.
…evaluate how repetitive or simple tasks can be automated — thanks to the almost infinite world of tools many things can be automated to save time again.
…optimize report/ticket contributions through “Issue Forms“ — with the introduction of GitHub‘s fantastic “Issue Forms“ feature ¹³ back in 2021 I noted this directly as a workflow improvement that I want to adapt for all of my projects. Currently, every Nord repository has it‘s own issue & pull request templates, which of course were a relief after the introduction too, but even though I tried to keep them more or less in sync, except for project specific content, it is also a lot of overhead to keep them up-to-date and also many of them are kind of “over-engineered“ with a lot of information a possible contributor/reporter must consume before actually opening the issue or pull request. Thanks to the relatively new GitHub “Issue Forms“ feature this can be drastically improved by making the process for users as easy as possible through a “guided“ form. For me as a maintainer it is very easy to create, customize and maintain the forms due to the easy YAML syntax that also comes with advanced form schema configurations to adapt every use case and project needs.

Tools Are Key #

However, a well thought-out workflow is not really effective if the appropriate tools are missing. This can be supportive tools for planning & documentation purposes like GitHub‘s “Projects“ feature or application that generate content based on templates, data sources or use cases. No matter how these tools are used, in the end they help maintainers and users alike to simplify tasks and reduce effort.

My plan for Nord is to use a few of the fantastic tools that already exist and to develop others myself that are precisely tailored to the project:

More build & release process automation — GitHub “Actions“ are a perfect CI/CD integration that lives next to the project itself. Right now only a small amount of Nord ports make use of it, and if so only for code style checks and linting. However, building new versions and releasing them is still a manual process that also takes more time than it appears from the outside world. This includes the tasks that are described in sub-item 1.1 below and will, when being automated too, save a lot of time and allows to follow the “Release early, release often“ principle instead of queue a certain number of (unrelated) changes. Building within CI environments is also the way to make “reproducible builds“ while local setups can change and do not represent a “neutral“ environment. Pushing build artifacts, regardless of whether (pre-)release or development versions, from local system to registries, e.g. like Docker images or npm packages or Visual Studio Code marketplace extensions, is not effective and setup can cause problems and also needs maintenance to keep it usable. Therefore, outsourcing the CD process to systems intended for this purpose such as GitHub “Actions“ saves time and nerves.
1.1. Release notes & changelogs generation — based on the information written down in the “Quality Is In The Details“ section above, the task of creating release notes and changelogs will be automated in way that still keeps the way how these documentations are written, but will be more automated, e.g. by using templates and the GitHub API to fetch and fill information from resources like issues and pull requests. I am currently trying to keep the structure and visual presentation of the release notes and changelogs of all ports the same, so it will be possible to use a kind of automatic generation with information from GitHub issues, pull requests and partially Git commits on the basis of templates.
Nord (TUI) CLI (and maybe a desktop application) — This point is something that I had planned for a long time and in the end it will be beneficial for everyone: an (interactive), unified CLI that acts as a single-source-of-truth application for Nord specific tasks, no matter of maintainer or user. It will be built with the my all time favorite programming language Go to provide functionality like data generation, e.g. release notes and changelogs like described in list item 1.1 above, as well as the automated (un)install process of some ports. The latter is, if at all possible automatically, at the moment solved by shell scripts that are located within the project itself and these are often duplicated code copied from one of the other ports. Trying to update these often means that it must be done for other ports too which is an annoying overhead and waste of time. In addition, shell script languages are more than suboptimal due to the huge number of differences in versions, interpreters, platforms and compatibility problems and should therefore only be used as an temporary solution or for “direct execution“. Building a stable, typed, cross-platform and lightweight application, that can be used for all ports, with a fantastic language like Go instead provides much more freedom, confidence and way less maintenance overhead. It is the perfect solution for users as it runs on all popular and common platforms and systems ¹⁴ ¹⁵, which cannot be said of scripts. Thanks to the great ecosystem of Go ¹⁶ ¹⁷, and the fact that it is increasingly becoming one of the best and most widely used programming languages (see the great GitHub CLI project), also allows, if necessary and requested more frequently, to create a desktop application afterwards to get users on board that are not that familiar with (TUI) CLIs.

Finally Complete The Move To The New Home… #

With the initial launch of the website the transition of all port and non-relevant Nord data into the “new“ (and currently named) nord-docs repository, including the migration of the actual content into the documentations, has also started. The progress status is tracked in arcticicestudio/nord-docs#133 and many larger and popular ports have already been migrated. This means the dedicated home page per port is available, the corresponding repository has been cleaned and any shared, common resources and project-only metadata have been moved into either the (currently named) nord-docs or assets repository.
Overall, I was busy with this task for over 9 months and there are still many port pending. After this long time, in which the usual tasks of the project also had to be performed, at some point the motivation was very low and I needed a break from this repetitive task. Up to today, there was still no progress and the same ports are still pending, including all ports targeting “terminal“ applications that are similar to each other and only differ in some small aspects. These will therefore use common components and pages instead of individual ones per project and will be processed in one larger code change.

Anyway, this task blocks completing other tasks as these are based on the outcome of it. The focus and the priority will therefore be to complete this task in order to finally get the other project areas rolling again. Please see the “Feel More At Home“ section below for more details about the plan for the website.

…And Tidy It Up #

When the data transition is finally finished, the next step will be to clean up and do things right that have gotten stuck over time. As an excerpt that would be refactoring and improvements of initial implementations like UI elements, the way how data is handled, the overall visualization and the deployment process. More details are written down in the “Feel More At Home“ section below.

Feel More At Home #

The launch of Nord‘s website was planned by different design and architecture concepts to make sure that the goal of the project is written down as a way of orienting the implementation. After the last concept was finished, the site was published to the production environment in the first version, which was sufficient for the beginning to meet the set goals. However, it was already clear at the time that the implementation was just the beginning and improvements would be made later based on developer and user experiences and new possibilities of the technology stack.

The following points are a rough overview of the planned changes:

Migration to TypeScript — the list of advantages of TypeScript over JavaScript is long and for someone like me, who always prefers type-safe languages and never really liked script languages apart from unnecessary effort and runtime overhead, it was soon clear that Nord‘s website will also migrate to TypeScript later on. The use of React‘s prop-types was only a temporary solution to have at least a minimal level of security, but in the end it brings almost more effort than benefits due to the hardly available tool integration and possibilities. Because I use TypeScript in other projects and optimized my own tool box, e.g. my custom ESLint TypeScript specific rule set package, the migration will be smooth like for other projects I already migrated. The goal is to have a much better, maintainable source code basis at the end, which makes working on the project much easier and, thanks to more type-safety, also easier to expand. This way will greatly improve the developer experience, tooling support, stability and lowers the hurdle for new contributors. It has proven to be good for larger, community-driven projects.
Simplification and optimization of the structure and components — The initial goal of creating a usable website did not include making the source code “beautiful“ and optimize it. For example, currently many components are duplicated or differ only minimally and could be rebuilt for universal use with the ability to dynamically adjust properties. This task becomes even easier after the migration to TypeScript, since the developer tools clearly help to improve the source code and eliminate possible bugs already during development instead of causing problems during compile or even runtime. Another example of the current source code are visualization components like SVG “wave“ illustrations which are created as a single-use file and basically structured the same way, but usually only differ in the actual path data. Therefore universal and unified components are a cornerstone for good source code and are essential when it comes to extending a project. With the completion of this task, the structure and maintenance of the project becomes easier and new features can be implemented faster and better.
Upgrade to Gatsby v5 or migrate to Next 13+ — The website still runs Gatsby version 2.15.x which is way too outdated. In order to take advantage of the fantastic new features and improvements, the site must be updated in chain to v3 → v4 → v5. Even though this will definitely cost a lot of time, it would be worth due to performance boot and way better developer experience.
Another idea I had was to migrate to the awesome Next 13 that comes with “magic“ out-of-the-box server-side support using React server components and tons of other mind-blowing features. At the time when I started to build the website, Gatsby more or less the standard and, up to today, I‘m really satisfied with it, but it also got more complex and today Next is the way golden standard with a larger global adaption and more stable future. Thanks to Netlify‘s Open Source Plan a server-side application is now also possible for Nord where before I had to rely on pure static hosting with Gatsby. The integration with Netlify will be even better since Gatsby will join netlify, announced on 2023-02-01, which means that the whole Gatsby Inc. teams will now be part of Netlify.
Both ideas require more evaluation whose results will be made public, but the rough direction should be clear from this list point.
Fill the blog with life — the actual implementation of the blog was already finished with the initial website launch, but I never got around to actually using it. One reason for this is that an important functionality was not included in the implementation: the use of SVG images as header or dynamic content resource. This may sound a bit strange, but visual elements are a very important aspect for the division and presentation of content. Even if the implementation already allows to use “normal“ photographs, the style of Nord is based on the minimalistic design and the fact that SVG graphics always ensure a high quality, regardless of the resolution factor. In order to finally be able to productively use the blog, this feature will be implemented next.
Optimize resource sizes — even though bandwidth is no longer a concern for most internet users these days, it‘s still important not to let resources grow unnecessarily large without real benefit. This is most noticeable with images (except SVGs), as these are usually the largest (static) assets, but do not require full resolution if they are only displayed in a small format, e.g. when forced to adjust to a small container on a website. Often these images are the full resolution instead of a optimized image whose resolution has been reduced to match the surrounding container. This problem is currently also true for Nord‘s website and documentations since the goal was to get it up and running in a useable state while such improvements were secondary at first. Thanks to Netlify the website is hosted for free, running on one of the fastest and most reliable networks and comes with a lot of fantastic features. However, the “free plan“ of course also comes with limitations, which includes the limitation of “high-speed“ traffic per month. In fact, Nord exceeded the traffic limit, due to reference links from some larger sites where Nord was discussed, which caused an automatic purchase for the upgrade bundle. As the site has grown in content and popularity this limit has been pushed more and more month by month and I now receive regular emails that warn that limit is almost reached and data transmission will be throttled. The limit has not yet been reached and the month was ending so that the traffic was reset for the next month, however this will no longer be the case with the further development of the website. To be honest, I had to manage and prevent an impending account suspension due to the (unwanted) bandwidth expansion package because I wasn‘t willing to pay such a high amount of money for it from my personal pocket. Thankfully the fantastic Netlify team helped and jumped in by upgrading my account for Nord to the great Open Source Plan which should prevent such problems in the future and also enables possibilities to extend Nord‘s website. Optimizing resources and the data traffic is a large topic and there are awesome references like web.dev that are all about web development, providing “best practices“ and tons of useful information and guides, e.g. how to efficiently encode images. Since images also currently consume the most data volume Nord‘s website, this will be the optimization step. Thanks to Gatsby working with images in Gatsby, the same can be said about Next‘s image component, it‘s a breeze already anyway with optimization features like the pre-optimizing of images and other out-of-the-box features that prevent image bloat as well as handling media at all. With a smaller footprint and reduced data usage the UX for Nord‘s website will be improved a lot while helping me to worry less about hosting problems in the feature without having to move to a self-hosted server or use a payed plan. Nord follows the JAMStack fantastic principles , the modern way to concept and way to think for pages, and these steps are definitely parts that require some more focus.
More modern design — even if the first version already has a quite modern appearance, I had ideas from the beginning to incorporate further aspects from my other projects as well as inspirations from other projects and fantastic sources like Dribbble. Among other things, this includes improvements to the structure and components of the main landing page and the ones from ports, such as more compact containers that show features, e.g. by using tab-based switches instead of “image-text duos“. An important point is the improvement of the documentation in aspects such as clarity and, above all, the navigation, which is currently quite cumbersome and is only possible by using the browser‘s “history“ function (back/forward). The presentation of content is also not optimal and requires improvements for readability, linking and the targeted recognition of information. In some cases, the available space on the end device is not addressed dynamically enough and content is unnecessarily squeezed. On the other hand, content on landing pages is sometime too “long“ and navigation is more difficult to reach due to unnecessarily scrolling. The current basic scale size, e.g. for fonts and therefore the sizing of elements that are based on it, is also not optimal and the complete scaling will therefore play a major role in improving the overall appearance and structure of content. These and other aspects that were not mentioned will give the website and documentations an even more modern design and at the same time improve the user experience significantly with best practices.
Say “Goodbye“ to Google Analytics and “Hi“ to open source, self-hosted solutions — the design concept for analytics and statistics initially introduced the plan the use Google Analytics for the beginning and the reason, next to the ones described in the concept, why the decision for it was made is simple: it can be used free of charge. Using an open source solution such as Plausible would have meant that a dedicated server would have been necessary which, like mentioned in the section about sponsoring, is nothing I‘d pay from my private pocket for a project everyone can use for free. With the all the way how users can now become a sponsor of Nord would make this possible and is one of the goals for the ecosystem improvements described in more detail in the “Building A Dedicated Infrastructure“ section below. Once this solution is built I will happily remove Google Analytics as either way it‘s a too complex and bloated tool for a project like Nord.
Roadmap(s) and changelog(s) — two features I‘ve always wished for are dedicated pages for a project roadmap and (per-port) changelog(s). At the moment, this information is spread across a wide variety of sources and port repositories and does not allow for precise referencing and administration at a central point. But one of the biggest disadvantages is the limitation when it comes to the design, since these are currently mostly written in Markdown and a visual appearance with its own structure and modern elements such as animations is not possible. Dedicated pages, on the other hand, offer the possibility of absolute design freedom and an optimal presentation of information without having to store such information in the repositories of Nord and the ports themselves.
Library for community creations — as described in the section on the current scope of the project, it is now impossible to keep track of all the creations and custom projects of the community that are built on top or with Nord. I try to keep adding to my own lists whenever I see them, but I‘m sure I lost track years ago. It have also often been asked whether an official “Awesome List“ can be created in order to try to document it there, unfortunately there has not been enough time for this so far. I would like to change this as well and that‘s why the idea was born to expand Nord‘s website with a kind of (interactive) library for any kind of community creations in the future. This will include custom ports, new projects that use Nord, art and assets or even online articles about Nord. However, it is important here that artistic resources like images must be self-created and not existing ones from artists where only the colors were exchanged with the ones from Nord. This is an absolute no-go and violates the copyright of the creators who often make these images to earn a living. Sadly I have often read sentences like “But I‘m writing that the author has all the rights and then it is O.K. that I claim that I modified it“ and I can only answer such stupid statements with a simple analogy: if I steal your homemade chair, recolor it and then sell it at the flea market as my own creation and only briefly mention your name when selling, how do you feel? It‘s no different with digital creations and no other rule applies just because you can theoretically duplicate them infinitely and therefore never completely steal them. And anyone who thinks to reply to my opinion with NTFs will be blocked immediately. I don‘t tolerate such scam and rip-off trends for a second. Anyway, with such a library I want to try to do justice to the fantastic work of the community and make it easier for all users to find new resources.

Nord‘s New Home On GitHub… #

A foretaste has already been given in other sections about nordtheme, the organization that will be the new home of Nord on GitHub. I‘ve explained my decisions about the project identity & branding at the time and in the same course also its drawbacks which will be remedied with the migration to the nordtheme organization.

The tooling and management features for GitHub organizations opens up so many new possibilities for problems that have crystallized over the past few years of the project due to its increasing size and popularity. But this is not only an enormous step forward for me as maintainer, in the same way it also comes with many community improvements and features for the users:

All projects in a dedicated place with better naming — Right now all Nord repositories live in the arcticicestudio GitHub account where the naming convention is to prefix them with nord-. The problem is the discoverability and visibility which suffers due to the GitHub “person“ account type as other projects also live in the same space and users only know that these are the official projects due to the more or less common knowledge that Arctic Ice Studio is the branding behind Nord.
With the help of an organization, these problems can now be solved because repositories not only no longer need a prefix, but can also be directly recognized from the “namespace“ that the scope is purely the Nord project. This is reflected, among other things, in the URLs which include the nordtheme scope, and the overview of all repositories in an organization allow an easy way to search for ports and other Nord projects.
Read the section below about central project planning and issue management for more details.
One place for discussions… — The section about the plans for using GitHub “Discussions“ for Nord already goes into detail about what is coming for Nord in terms of community interactions and it also mentions that another advantage of an organization is that a “global“ discussion can be enabled for an entire organization in addition to individual repositories. This is one point on my list that I was patiently waiting for before publishing Nord‘s new plans at all because creating multiple discussions per Nord repository was not an option and would have caused even more overhead. Thanks to the continuous development of the GitHub platform and the inclusion of feedback from the actual GitHub users, this is no longer a problem because the nordtheme organization Discussions will be the single-source-of-truth.
…and project boards to rule them all — like the list point above, Nord‘s new project boards will also live in one place bound to the organization rather than being distributed over all repositories. This makes it much easier for me as maintainer to keep track of all ports and their tasks while users will finally get an overview and more insights about the actual workload that is currently hidden between individual per-repository boards. The section about the central project planning and issue management provides more details about this topic.
Keep up-to-date with Nord by following the entire organization — one of the latest features of GitHub is the new “For You“ feed ¹³ that was introduced in March 2022 and includes updates of all GitHub organizations you follow. This allows Nord users to keep up-to-date with everything happening in the Nord project on GitHub without the need to either enable notifications for everything or specific events in individual repositories or manually check repositories from time to time. Instead users can follow the whole nordtheme organization]and will be informed about the latest Nord changes, bundled in one place.
Fine-grained (repository) settings for contributions, community moderation and user permissions — As a “person“ GitHub account the possibilities are more or less quite limited when it comes to ways how to allow external contributions without exposing too much permissions to repositories. Even though I‘ve always wanted to add contributors to some Nord ports the limitations prevented it without the risk of maybe allowing users to merge changes that they thought are valid for the project but in fact included personal preferences. Not only that but the fact that it would also be possible to change repository settings, e.g. the visibility (public/private) was a deal-breaker.
An organization, on the other hand, comes with way better features to set finer-grained configurations to work around these problems and includes many more ways for me to globally set settings instead of having to go through all repository one by one.

I‘ve probably forgotten other points, but I think it‘s already clear why an organization is the way to go.
With all that said the Arctic Ice Studio branding will slowly but surely fade out when it comes to the Nord context while the in-person representation will be more focused on me, the single human behind Nord.

…With Central Project Planning And Issue Management… #

I was very excited at the time about the announcement of the new GitHub project planning features because this is another step in the right direction to make it easier to manage (large) projects and reduce the overhead. Even through I always liked the previous functionalities to manage issues there were also some features missing and sometimes it felt a bit sluggish and laborious. The announced features start right at the pain points and I can confirm that the features, that were made available to today, are game changers.
This is particularly noticeable when managing several repositories where project boards were previously scoped to them. Like mentioned in the sections about quality gate management and plans for more fluid and automated workflows, the overhead of sorting issues into boards is way too high and it is also really complicated to keep track of the dedicated “Support“ boards that also live in each repository.
Thankfully this will change with the new projects boards, the previous ones are now called “classic“. With the active development of “issues“ and continuous inclusion of user feedback, the new project boards can already be used in “production“ to today.

I learned about the new project boards by creating (private) projects that are bound to my user account to get a feeling for the workflow. Even when these boards are not visible to others I used them to get some “real world“ experience through Nord as well as other projects and I‘m very happy with the result.
The new nordtheme and nordtheme-community organizations will make the project management a breeze by providing the home for all organization-scoped project boards which will allow to manage everything in one place, including a single “Support“ board. As of today this is the new single-source-of-truth for Nord‘s centralized project management and iteration planning. Everything in one location to prevent information from getting out-of-sync, tracking release dates, create filters for every use case, building and sharing roadmaps, having an overview of all user support topics and much more.

In summary, “the new order“ in the current organizational chaos will bring…

…one dedicated place for all project boards — the current state of the project boards being spread across every repository is a management nightmare as soon as the amount of repositories rises. Thanks to GitHub‘s fantastic overhaul of the “issues“ feature and its continuous development this “organizational eyesore“ will be no more: introducing Nord‘s single-source-of-truth place for project boards, living in the nordtheme GitHub organization instead of individual repositories!
The initial migration of existing boards will also be easier thanks to the the feature of copying an existing project.
…“real roadmaps“ instead of simple boards named so — projects can be configured with different layouts for a view, e.g. tables or (kanban) boards, but thankfully the latest addition is a “roadmap layout“. This view is currently in public beta and I‘ve been recently invited to join the beta so the nordtheme will make heavy use of it and will also provide feedback to make it even more awesome.
…“real epics“ instead of simple issues named so — with the introduction of the new “tasklists“ feature the days are gone where simple issues had to be used that served as a kind of epic, but did not provide any features of an epic at all. The new tasklists will change this and finally a structured tracking will be possible with a smooth integration into other features, e.g a small badge will be displayed in project boards of many tickets are open in an epic issue or the indication in issues, in form of notice, that are part of an epic.

…And A Space For Community Creations #

Not only Nord itself will get a shiny new home on GitHub but I also finally want to create a space for community projects and creations on GitHub next to the home places of the community. This is where the new nordtheme-community GitHub organization comes into play to act as the place for resources like unofficial ports and other projects created by the Nord community, users like you.

The reason for it is that such resources are scattered around GitHub or other platforms without a way for users to find all of them, including me like I explained in the in the section about today‘s project scope and the fact that I‘ve lost the overview of community projects and creations a long time ago.
Providing a central and “official“ space for them comes with many advantages for all, users as well as me as maintainer:

Everything at a glance — With all projects living in a single GitHub organization there is no more need to try to keep track of other platforms and GitHub accounts or try to keep “Awesome Lists“ up-to-date. The organization can be the starting point for the “library for community creations“ idea, introduced in the “Feel More At Home“ section above, where the community can start to collect and persist resources which can be consumed by the dedicated web page or application later on while acting as the central source for Nord users in the meantime.
Scoped discussions and knowledge — While the nordtheme organization is mainly focused on “officially supported projects“, including community interaction places like the organization-scoped GitHub “Discussions“, the nordtheme-community organization will be a place for everything that is relevant and current in the world of Nord community projects. See the “GitHub “Discussions“ — The Long-Desired Solution“ section below for all details.
Use the fantastic GitHub features all together — Not only features like the dedicated GitHub “Discussions“ for Nord and unified namespace for repositories can be used but anything from universal “Actions“ for automation and central project boards are a great way to bring together all projects in a clear presentation.
An “incubator“ for potential official projects — No matter if it‘s unofficial ports or other community creations, e.g. artwork, the nordtheme-community organization can be an “incubator“ for projects that could be moved into the nordtheme organization sooner or later if it turns out that it is stable and actively maintained, well developed, popular enough and fits Nord‘s vision. There are already fantastic and popular projects out there and I hope that their maintainers will welcome to move them into this organization.

As you can see there are many great ideas and the list is not complete at all so I hope, and I also strongly assume that, this will be an absolute asset to the community.

Catching Up On The Backlog #

Finishing the blocking task of transitioning port data means that there is finally time to work on the heap of issues, (support) requests and community contributions that have accumulated for a long time. Even if I can quickly see when new inquiries come in through notifications, regardless of whether they are on GitHub, Reddit, Mastodon, or Twitter or any of the other “official“ community platforms, there is simply almost no time to look at them more closely and react. In the past (and unfortunately still at the moment) I only briefly added meta information to new tasks and then put them in the queue. The whole thing then grows quite quickly over time to an extent that cannot be completely processed with a little more free time. Especially not when other important tasks require more attention.

But all of that should finally change as soon as these important tasks are finished and their result will help to process the bunch of tasks more efficiently and better. With more fluid and automated workflows as well as a supportive box of tools, the processing of these tasks will become much easier and over time it will even out the number of open tasks.
The goal is to…

get an overview of open contributions and issues that are pending for a long-time.
1.1. pull requests will be, if appropriate, merged so that the subsequent changes do not depend on them or even maybe conflict with the contributions.
sort and prioritize request for features and improvements, open bugs and problems to evaluate their implementation and the release plan.
create and release new versions in the planned iterations for a continuous feedback process.

The Home Of The Community #

Since the growth of Nord it has always been important to me to offer good and safe places for the community to work together or just chat about it. Like described in the section about the ecosystem above, this has been kind of challenging because it is difficult to gather everyone on a a single platform. On the one hand, the wide range of different platforms is of course good to avoid vendor lock-in, but then of course it is difficult to see the community as a whole. For Nord the initial solutions were characterized by the fact that the platforms had to be free of charge and be based on open source projects. Of course, platforms like the /r/nordtheme subreddit are an exception when it comes to the second point, since they are almost a standard. Others like @nordtheme@fosstodon.org and @svengreb@fosstodon.org on Mastodon or @nordtheme (previously also @arcticicestudio) on Twitter can be seen more or less like a way for announcement and asynchronous communication instead of a dedicated platform.

In the following sub-sections I want to go more into detail what will be changed and what is coming up for the community and its management. This will include information about a central platform for community content, help & support and a new decentralized way of communication that is central at the same time. I know this sounds a bit confusing, but you will understand how this works in the sections below. The sections above about real-time conversations and how they will evolve also already provided information about the history and current state while the following sections will describe what exactly will change.

GitHub “Discussions“ — The Long-Desired Solution #

When GitHub announced their new “Discussions“ ¹¹ feature during the “GitHub Satellite“ event in 2020, the wish of countless open source maintainers came true. User support and also announcements that used to be regulated in a cumbersome way using single issues in project repositories, which was never designed for it, will be possible through a dedicated kind of forum that also lives directly next to the project sources itself. Announcements and project-wide information will no longer have to be distributed via other channels such as Mastodon, Twitter or Reddit, which often only really reaches 50% or less of the users and have to be repeated in issues many times again, but will be possible directly within the scope of the repository itself. All in all the perfect solution for the open source ecosystem. During the (closed) beta phase, I planned the usage for Nord since the decision to introduce this feature as the central community content and support platform was clear from the first second.

→ Welcome to Nord‘s “Discussions“!

Of course the official /r/nordtheme subreddit will stay since it is a different kind of content, but the focus of Nord‘s “Discussions“ will be more for technical and supportive topics. The same also applies for platforms like Mastodon and Twitter which will of course continue to be used as before, bit Nord‘s “Discussions“ will become the single-source-of-truth for…

project-wide and per-port announcements — distributing information is not always as easy as you think and a common reason why false information arises from untrustworthy sources. Moreover, it is not always easy, or even rather impossible, that these really reach all users and is the reason for false information in so many aspects of life, not only in IT. At the moment I‘m trying to distribute important, project-wide information for Nord via platforms like Mastodon, Twitter, Reddit or via GitHub issues in order to cover as many people as possible and to be able to refer to them in case of questions. However, a central source, to which one can then refer in posts on other platforms, is the most optimal solution. A good example is an official blog, that will be used for Nord later as soon as it‘s finished, but GitHub “Discussions“ is at least as good and as close to the community as possible, making it a perfect solution for any global or per-port announcements and information.
technical topic discussions not directly related to code — a not uncommon topic in GitHub issues are topics that are not directly related to the source code but rather based on technical suggestions or questions. Even if this communication medium is not optimal, before the release of GitHub “Discussions“ it was pretty much the only way when it came to placing it as close as possible to the repository itself and also the easiest way for when you‘re a GitHub users anyway. These kind of conversations are now also covered by Nord‘s GitHub “Discussions“ and offers the optimal platform for such topics with all the comfort and communications features.
user support and help — As already described above, I have to spend a lot of my project time is spend for user support and assistance which has nothing to do with the source code and therefore absolutely does not fit into the functionality of GitHub issues. Unfortunately, as in the previous point, this was the only way for many users to describe their problems if they did not want to ask for help in Nord‘s real-time communications platforms. With the introduction of “Discussions“ this is finally history as it offers the optimal solution for this kind of support, powered by the community instead of being placed in GitHub issues that are spread over various repositories and cannot be actively followed by all users.

GitHub as the central platform is constantly developing and so “Discussions“ is also continuously being improved with the help of feedback from its users (funnily enough, by using itself as the feedback tool). With its community insights feature it will help maintainers a lot through useful information like number of Discussions, issues, and pull requests open over time as well as many more statistics and data that make it possible to keep track of a project. I am particularly looking forward to the possibility of activating “Discussions“ for an entire organization in addition to individual repositories, which is a must have for large and modular projects like Nord. Also see the plans for “Discussions“ in the nordtheme and nordtheme-community organizations in the “Nord‘s New Home On GitHub…“ and “…And A Space For Community Creations“ sections.

Real-Time Communication — Welcome To Matrix & Discord #

Communicating with others is an important aspect when a community shares an interest in a topic. While the sections about the current status and the overview of what will change already describe the status quo and the overall plans for Nord, this section will give details about the actual changes.

One platform to rule them all — Welcome to Matrix — the open network protocol and ecosystem of the future for decentralized, transparent and secure communication that is completely open source and powered by the community. It offers everything your heart desires when it comes to exchanging with others: text messaging, audio communication via VoiP, video calling via WebRTC through various integrations like Jitsi (Meet) and the almost infinite possibility to extend functionality and sync with other platforms thanks to “bridges“. It is a fast growing and really actively developed project with great ambitions and I‘m really happy to announce that it will be the main real-time communication platform for Nord. The complete control over the data is the responsibility of the operator of a homeserver and is therefore the perfect solution for open source projects.
Introducing Discord — other platform, same community — even if Discord is a purely commercial project, it has (unfortunately) become an established communication platform. Beginning to compete with, or even supersede, TeamSpeak, today it is one of the most widely used applications for communities of all kinds of interests and Discord also tries to get open source project‘s attention so that they choose their platform for their user base. So far I have tried to avoid to use Discord for Nord, but it seems that there is no way around it and the number of requests for an official server has increased in recent years. Therefore, there will also be an Nord Discord official server in the near future, but users must note that their privacy and data security is in no way protected and accept the fact that there are endless security flaws so they use the platform at their “own risk“. Moreover it will not be a “first-class“ platform and the interactions will be synchronized in the future with the Matrix homeserver, using a “bridge“ for Discord. Thanks to this, it will be possible for both platforms to interact with each other and thus create one large community instead of forming two “subcultures“ again who both live in their own cosmos.

Some of you might ask yourself “And what about Spectrum, Keybase and Slack?“ and the answer to that is simple: they will be sunset. You can find out why and when in the section below.

Fill The Blog With Life #

Finally finishing the remaining implementation for the blog is one part of the development focus to make Nord‘s website feel more like a real home for the community and the project itself. In the section above about the introduction of Nord‘s GitHub “Discussions“, I mentioned that an optimal solution would be the use of the blog for project-wide information and announcements. This remains the goal and together with the planned changes it is a goal for 2023. All the important announcements, interesting and worth knowing information, insights and much more will fill it with content. Certain information is also published in Nord‘s “Discussions“ in order to achieve good distribution, but the blog is one of the important and central sources.

Make Better Use Of Existing Platforms… #

Nord‘s current main platforms are already living places with daily interactions, however, there are still many features that have not been used which leaves a lot of potential. The official /r/nordtheme subreddit contains many posts with various topics, but until now I haven‘t used great features like scheduled events, posts with polls or a subreddit-wide chat about a specific topic. Mastodon accounts like @nordtheme@fosstodon.org and @svengreb@fosstodon.org or Twitter accounts like @nordtheme (and previously @arcticicestudio) are currently used to post announcements, share interesting content about Nord or simply talk about different development & design topics. However, there are also features like polls that were not used even though I had some uses cases.
While Nord “Discussions“ and the official blog will serve as the main sources for the future, /r/nordtheme, Mastodon and the Twitter accounts are the platforms for quick posts and community interaction.

…But Also Say Goodbye To Some Others #

It‘s important to tidy up from time to time and it‘s the same in the digital world. In this case the focus is on all of Nord‘s current real-time communication platforms, from the official Nord team on Keybase to the (already read-only) space on Spectrum and the Slack workspace that never went public anyway. The sections about the current status and the overview of what will change provide more details about this topic, but this sections contains information what will actually happen.

Sleep well Spectrum — with the announcement of the sunset and read-only mode of Spectrum the end of the Nord space was also sealed. It served well and the content will be available as long as Spectrum keeps the systems running, but now the official Nord space is be closed and no longer actively supported.
“Bye Bye“ Keybase — good core idea, poorly managed — with the idea of making end-to-end encryption more accessible to the masses and combining this with essential functions such as chats and data sharing, was a terrific. Unfortunately, it failed again because of the problem that mankind has created itself: greed for money. On May 7, 2020 Keybase (proudly?) announced that they have been acquired by Zoom, the application that has more security holes than a sieve, starting from false end-to-end encryption claim, ways to simply join any meeting and a totally messed up code base that runs a local server on the users system, allowing smart people to get into their systems. All of this is driven by a company that has never heard of transparency and trustworthiness. In summary one can say that it is the exact opposite of what Keybase has set as a goal to fight. The disappointment among the users was great as offers from the community to support the project financially were rejected for years and suddenly money was more important than ideals. Keybase was so promising and, among other great repositories, the client is still completely open source and really advanced, although there was always some criticism that the server was never made public too. Since the announcement of the acquisition, things have been going downhill and it‘s only a matter of time before Keybase disappears from the scene again. Various projects like the Matrix “bridge“ for Keybase were discontinued and deprecated almost immediately because of this breach of trust. For the Nord team on Keybase this also means that as of 2023-02-03 it will be closed and no longer actively supported. With Matrix (and partly Discord) being the main platforms for Nord, Keybase is not needed anymore anyway and will therefore not be missed in the slightest.
Nord on Slack — gone without ever really being there — the last platform is also the least important and the one that nobody will miss. Even though I created an official Slack workspace for Nord, it was never possible to use it easily. There is no way for users to simply search for a workspace and join it but only through time or usage limited links, generated by an workspace administrator. This is a lousy solution and thus this platform was already dead before it could ever reach the Nord users. Of course Slack was not in the least a solution that met my requirements for a free platform, but is also driven by a company that is becoming increasingly greedy and is therefore not a loss for Nord at all. The reason I write about a platform that was never publicly accessible is that it was advertised on Nord‘s community page and I want to be fully transparent about the fact that it will disappear from this page in the near future again.

Retire Arctic Ice Studio As Nord Brand… #

I made the decision to retire Arctic Ice Studio as the brand for Nord.
As of today Nord drives under the flag of the new organization scope, leaving behind the bumpy years of the misleading branding.

Like described in the section above about the branding and its drawbacks, the plan to move Nord and its repositories to the nordtheme organization does not help for the problem that there is still no solution for the best handling when converting a user account to an organization, e.g. without the loss of commit author linking, followers and stars.
Therefore, I have planned the following steps to work around this problem:

Notify sponsors and followers to adapt — for large changes like this communication is key. Due to the project history the arcticicestudio account (only at the time writing this) has more than 1600 followers and in average 6 sponsors with monthly repetitions as well as one-time donations. Notifying them individually about the changes and to suggest to “switch“ to my personal account is not an easy task. This includes information about how everyone can also follow the new nordtheme and nordtheme-community organizations thanks to GitHub‘s relatively new feature that allows to not only follow person account but organizations too that was introduced in March 2022.
Clean up GitHub stars to separate scopes — the arcticicestudio account currently has a large number of GitHub stars, which are not only related to design and theme development, but are sometimes more relevant to all my other projects. On the other hand, my personal account also has stars that basically only play a role for Nord. In order to untangle this mess, both accounts will be cleaned up by…
- …moving stars to the correct account while removing it on the other one.
- …sorting stars with the new and awesome GitHub “star list“ feature in order to achieve an orderly structure.
Moving “non-Nord“ repositories to my personal account — at the moment, repositories that are not related to Nord are also stored under the GitHub arcticicestudio account. Even if the arcticicestudio account was initially intended to be used for other projects too, over time I decided to use it only for Nord and to manage everything else under my personal GitHub account svengreb. Therefore, the following project repositories will be migrated in the near future, step-by-step with prior notice to educate users:
- styleguide-javascript, the Arctic Ice Studio JavaScript code style — the description of this project is a bit misleading because I use it for any other project too. Therefore, the move to the svengreb account is only an advantage to show that it is not a project that was only used for Arctic Ice Studio projects but is was just one user of it.
- styleguide-markdown, the Arctic Ice Studio Markdown code style — the same arguments from the styleguide-javascript point above also apply to this project.
- styleguide-git, the Arctic Ice Studio Git style guide — Again, this is definitely not a project that should only be used for Arctic Ice Studio projects but a general guide that can be used for almost every project. Therefore, in the near future, the new home of this repository will also be my personal account.
- igloo, the snowy dotfile home — this important project is at the heart of every developer and of everyone who values a well-kept, digital home. Since dotfiles are the essential part of every system setup, this repository initially started to not be specific to Arctic Ice Studio at all. Therefore this repository will also move to my personal account, making it absolutely clear that it belongs to a human and not a brand. The name will of course stay since there is no reason to change the topic just because the owning account is not one that comes with a dedicated theme.
- snowsaw, a lightweight and dynamic dotfile bootstrapper — basically this repository should not have been created in the arcticicestudio account from the beginning since it is also a universally applicable tool, but the initial reason was that it powers the igloo project and has a “arctic branding“. In the near future it will move to my personal account too.
- styled-modern-normalize, modern-normalize.css for styled-components — this project was created during the development of Nord‘s official website to simplify the usage of the modern-normalize.css project through a styled-component based theme. As with the previously listed projects, this project can of course be used elsewhere and will therefore also find a new home in my personal account.
Updating references and, wherever possible, IDs as well — even when many platforms used by Nord automatically adapt to identity and name changes, e.g. GitHub redirects to new locations when a repository gets moved to another account/organization or has been renamed, it still requires a lot of time to make sure that any other reference is updated to reflect this large change. A major challenge is the migration of content in form of plugins/extensions/add-ons/etc. that is published to platforms that require a unique ID, often in form of namespaces that include the name of the publisher, in this case arcticicestudio. The best example is the Nord port for Visual Studio Code which is available from multiple platforms like the Visual Studio marketplace and Open VSX Registry where both are owned by the arcticicestudio account which is part of the extension ID. What I definitely don‘t want for these extensions is to deprecate and replace them with a new one that is owned by my personal account or a dedicated one like nordtheme. This would mean that important aspects like the popularity ranking and the easy visibility in extension overviews would be lost, including all statistics about it. It is also the worst way for users to get to know about this large change and make them aware that they need to switch to the extension replacement. All this applies to many ports such as Nord for JetBrains, also published in the official plugin marketplace where there is not even an official way to “deprecate“ a plugin in favor of another one for the JetBrains Plugin Registry. This is a show-stopper and a task that will require time to make sure that the change is as smooth as possible for all current ports that suffer from the same problem.

Finally, I would like to say that Arctic Ice Studio is here to stay with its founding idea as a branding, but it won‘t be an active part of the Nord project anymore. It has been an important part in the history of Nord and might act as the same for other projects in the future.

…And Put More Focus On The Human Behind It #

With the retiring of Arctic Ice Studio I also want to achieve the goal of a better clarification about the human behind Nord.
In the upcoming months Nord‘s website, documentations and repositories will include more information about who is working behind the scenes. Hopefully this will be a step forward to reduce the current drawbacks of the decision to use a brand for Nord instead of my personal identity while making it easier for me to separate the management of Nord and other projects. When it comes to sponsoring Nord it will also help to clarify what is the goal of the sponsorship rather than a semi-transparent overview of where the money is actually used for.

With svengreb as the main representative identify there are tasks in order to communicate this for Nord on platforms other than GitHub.
Arctic Ice Studio accounts like Twitter or Reddit are currently representative as Nord maintainer and also act as origin for announcements and official replies. In case of Twitter the account has also become a cross-topic sharer that not only relates to Nord but also distributes a lot from the open-source world in general and is part of many followers and lists daily information source. This was also always the purpose of my personal @svengreb account due to my work on other projects and in the future this will also take over this task again while the @arcticicestudio account will slowly become more quiet.
For all followers who are only interested in content about Nord the @nordtheme account will start to finally become the active source for anythings around the project.
For everyone who also want more content and liked the “information mix“ of the @arcticicestudio account, are very welcome to (additionally) follow @svengreb. I will do my best to try to notify and inform @arcticicestudio followers to get to know this change and I hope that everyone understands this decision. For other platforms like Reddit or anything related to Nord‘s real-time communication channels the change is easier since this will just be a “switch“ of the actual project maintainer to svengreb and the nordtheme account that acts as a direct brand representative.
Of course the same rule applies like in the section above: The Arctic Ice Studio identity will not go anywhere or will be “deleted“ but only frozen for future plans not related to Nord.

Building A Dedicated Infrastructure #

I‘ve always been grateful for allowing the open source community to develop projects without worrying about investing money in infrastructure and tools. Many see it as apparent, for whatever reason, as a matter of course that this is available without having to spend a single cent for it. This way of thinking is absolutely negligent and inappropriate.
First of all I would like to thank GitHub which is basically the heart of the whole open source community and without this platform the community and a lot of projects would not even exist in the way they do today. No costs for hosting an almost infinite number of Git repositories, connected to a huge number of fantastic features like a ticket system and management boards as well as a complete, high-speed CI/CD infrastructure. That and so much more would cost four-digit amounts per month per project, but instead developers can worry-free just focus on development to build great things. GitHub is by no means the only company, but others like Docker Hub enables developers to store container images free of charge and services like Codecov analyze and prepare test results without charging you anything. It‘s also important for me to mention Netlify here, which not only provide DNS servers for free and automatic HTTPS, but even allows to host entire websites, powered by a huge high-speed CDN network and via SSL certificate, free of charge of course, thanks to Let‘s Encrypt, another well-known and free-to-use service. All of this is the reason why Nord‘s website, including the domain management, runs so well and smoothly without me having to pay money out of my private pocket for a project that is open source and free to use by anyone.

Now you can ask yourself what all this has to do with the topic of this section and the explanation is simple: even if a lot of things are free, one should never expect that this is the norm. In addition, self-hosting is awesome which is associated with fun and also offers many advantages compared to semi-commercial solutions and sometimes also free-of-charge ones. Often it is also the only way when you want to use an open source project since most of the time they are not provided as SaaS for free or not even available at all when the project is relatively small or not provided by the maintainers itself.
In the case of Nord it‘s about open source projects that I‘d like to self-host in order to improve the community interaction and possibilities even more and to make my work easier as a developer. Therefore the plan is to deploy the following projects in a self-operated environment:

Matrix homeserver — in the section that introduces Matrix as the new real-time communication platform for Nord, the plan is to initially use the public Matrix instance for Nord to get things up and running, but a possible future goal is to run a homeserver myself later on too. Even though the public instance runs smoothly, is reliable when it comes to the uptime and is by far the most active instance with thousands of spaces ¹⁸ ¹⁹, this would allow users to clearly identify with the Nord community when connecting to an instance running on the nordtheme.com domain instead of connecting to space on matrix.org. Thanks the fantastic Matrix protocol itself no data would be lost because there is a transparent synchronization between both instances, allowing users to either join the community from one or the other instance. As important as this is the usage of the Discord “bridge“ in order to also keep the Nord community of the upcoming Discord server in-sync. Matrix is documented really well and running the server, and optionally the client, yourself is quite easy.
1.1. (Optional) Element Web — basically, it is not necessary to host a Matrix client yourself, so this point is optional and does not have a high priority compared to the other ones. Like the public Matrix instance, Element is also available as a stable and free-of-charge service. Hosting an own instance is again only a plan to get full control of the deployment and responsibility, but for the beginning the public one, or any other client, can be used.
Plausible — like already described in list point 7. in the section about how Nord‘s website will be updated to make it feel more like a project home, the current usage of Google Analytics was just a initial solution that will was always be planned to be replaced by an open source solution. There are many good projects like Matomo, Umami, PostHog, Fathom and so on, but in my opinion the best is Plausible. It is a simple, lightweight, open-source and privacy-friendly alternative to Google Analytics that doesn’t use cookies and is fully compliant with GDPR, CCPA and PECR. It comes with first-class self-hosting support and the developers are proud advocates of open source. As soon as a Plausible instance is up and running in Nord‘s new infrastructure it will replace Google Analytics immediately and Nord‘s Google account will be cleaned and wiped.
(Optional) Fider — since the publication of the first ports, Nord‘s attention has increased and with it the demand for their expansion and new ports, which went beyond the initial goal of my personal use. The number of current inquiries and open topics is huge and the processing is an almost endless flow in which time disappears. One of the problems is the prioritization in relation to the real need and the classification in the backlog. Even if a port is requested for a specific application or platform, that does not mean that it has the same importance as another port or other tasks in existing ports or Nord itself. One way I‘d like to go to remedy this is to let the community vote on what to do next. Of course a suitable tool is required to manage this and that is the moment when Nord‘s new GitHub “Discussion“ comes into play, the new, forum-like home of the Nord community. With its help it will be possible for users to vote for tasks like new ports, features and improvements for existing ports and everything around Nord itself. Now of course one can ask what this has to do with Fider and the explanation is that I want to put it back as an optional solution in case GitHub‘s “Discussions“ feature doesn‘t turn out to be a suitable solution for it. Fider on the other hand is designed and developed just for this use case and might fit better. However, it‘s just not that close to the repository and has to be hosted externally which is a small hurdle and can only be solved when a dedicated infrastructure for Nord is available.

All of these (non-optional) points would be an absolute enrichment for Nord and the community, but there is one important condition: building a infrastructure requires a VPS (Virtual Private Server) or dedicated (root) server that must be paid and therefore depends on the the sponsoring of Nord through the community. The section above about where the money of sponsors is used includes details about how it helps me personally as a creator and maintainer, but also mentioned how it supports Nord to go on and improve. So sponsorships are a must for this plan, and with the versatility and easy ways to become a sponsor, anyone can easily contribute.

Of course I would also like to explain in more detail what the exact requirement is and what happens when it is met.
The initial plan is to rent an VPS because the resources required for the services listed above are not that high and it should therefore be sufficient for the beginning. If necessary, we can always switch to a more powerful server later on. The provider I trust is netcup, a company founded and mainly operating in Germany since almost 27 years that has won several awards and is a member of severals organizations that care about the web. I‘m a customer for my private servers for years, running Kubernetes clusters, and I was always very satisfied, starting from the performance to the stability as well as the reasonable prices. Therefore, the choice of provider for nord‘s infrastructure plan is easy.
The technology stack will be the following:

Arch Linux as operating system that runs on the bare metal that will be provisioned through (custom) Ansible roles, modules and playbooks. There will be almost nothing run in the host system itself but only in containers.
WireGuard, the extremely simple yet fast and modern VPN that utilizes state-of-the-art cryptography, which is the way-to-go for tunneling, fully cross-platform and shipped with the Linux kernel out-of-the-box. it will be used to access the running system externally to manage and maintain the infrastructure and services. This will be one of the few applications that will run n the host system to natively integrate with the OS.
K3s, a certified, lightweight Kubernetes distribution built for IoT & edge computing that, as the container runtime for all self-hosted services.
Traefik as router and traffic controller for all requests to the cluster.
Flux, the GitOps toolkit to manage cluster workload resources with Kustomize and Helm, that will be connected to Nord‘s (upcoming) infrastructure repository to keep the cluster in-sync.
SOPS, the simple and flexible tool for encrypting secrets, with the fantastic “Age“ project as encryption backend with Vault as storage. Maybe git-crypt might be enough in the beginning for anything else that must be stored securely in the repository. Since Flux supports (de/en)cryption via SOPS out-of-the-box it is the perfect solution for the cluster secret management.

To put all this into action the first goal is to reach a stable and reliable sponsorship amount of ~6€ per month. This will allow to get VPS model like the “1000 G9 12M iv“ that comes with 2 CPU vCores, 8 GB memory, 160 GB SSD disk space. A system like this should be sufficient for the planned workload and has a absolute reasonable pricing.
But to clarify again, the help of the community is required to turn this goal into reality!

Road to 1.0.0 #

In the section above about how a project should always pass quality gates and the important fact that quality only comes with time. Of course, this principle also applies to Nord and therefore the project and all ports are still published in major version 0. It follows the de facto standard versioning specification “Semantic Versioning“ (SemVer) and keeping the project in major version 0 allows to focus on bringing the project forwards instead of having to worry about migration management when introduction breaking changes and backwards incompatible changes. Nevertheless, during development, I still make sure that major changes are backwards compatible, but major version 0 allowed me to do breaking changes when there is no other way around.

With over 8 years of development, Nord now has become more and more stable, tested though daily usage and dogfooding and moves on forwards to become officially ready for production. Of course, this could also sound a bit strange for a project that basically only “arranges colors“, but here too changes can have a (negative) effect on users without this being the actual intention, resulting in a degraded user experience. When you compare the fact that ports have been downloaded several million times over the years against the current amount of reported problems, it is definitely possible to say that Nord has already reached a point where most of them are ready to go to the road to major version 1. On the other hand many ports also won‘t require updates in years and are almost completed and feature-frozen right after their initial major 0 release version which are mainly the ones that define and provide the colors for terminal applications like e.g. “Alacritty“, “iTerm2“ or “GNOME Terminal“. Ports for actively and regularly updated upstream applications like “Visual Studio Code“ or “Vim“, in turn, require more intensive care and effort and might introduce (breaking) changes more often, therefore it makes sense that these stay in major version 0 as long as needed until the confidence to leave that development state has been reached.

So what is the goal of reaching major version 1.0.0 and how is it defined? Roughly summarized the goal is to prepare and release existing ports in major version 1.0.0 as well as the Nord color palettes and switches itself. This includes the steps of…

…finishing the migration of ports to the “new“ website — as already described in the section above, this step is necessary to finally clear my head and concentrate more on pure development again. It not only helps to make the website feel more like a real project home but also reduces the effort required next to the actual source code changes in ports.
getting long-time issues and contributions into the code base — before actually moving a port to version 1.0.0 I want to catch up on its backlog to get finish open long-time topics like reported issues or pull requests so that the first major release version comes in a more or less clean state.

One point that I would like to address explicitly here is that the creation and publication of new ports has been paused a long time ago because the amount of open tasks is way too high and new ports mean more required time. At the moment the queue with proposals, requests and prototypes (“unofficial“) for new ports is at a count of almost 120+. The fact that the scope of the development of new ports is long beyond my personal use shows that more workload at this front is something I definitely want to avoid. Therefore development iterations for new ports will only start again after reaching major version 1.0.0.

It is also important to note that the goal of reaching 1.0.0 means that breaking changes won‘t be as easy as right now when leaving SemVer “Major Version Zero“. This won‘t be something that will block the introduction of such changes when necessary, but it will definitely require more time and effort to get these into the code base, including the migration step documentations for consumers and the distribution of this information via community announcements.

A Look Into The Distant Future #

The schedule for the topics discussed above is set for the near future, but I would also like to address topics that will follow later. Most of them are very large and therefore require a lot of time for planning and preparation. In addition, the priority of these is significantly lower than the topics that will start right after the publication of this announcement and are currently significantly more important for Nord. In the next few sections I will therefore give a brief overview of topics that will be tackled at some point.

A Bright Future — Light “Day“ Theme Mode #

From the beginning Nord was designed for a dark appearance. This is mainly because the basic idea was to create ports for my development tool stack where a dark theme simply improves concentration, readability, overall view of textual content and the focus. What a lot of people don‘t know, however, is that I always prefer light designs for UIs. This is mainly due to the fact that dark designs, in most cases, degrade or almost make the separation of the various UI elements unrecognizable. Dark appearances in UIs are usually very dull and text “shines“ too bright if the developers have not taken care that the chosen color palette is coordinated. The most stupid method, which is unfortunately used far too often, is that the color distribution is simply inverted or replaced by way too dark and bright colors like pure black (#000000) for backgrounds and white (#ffffff) for text. Elements between are colored with a slightly brighter black or some kind of grey which makes the UI look like a terminal from the 70s. Overall dark UIs often look “dirty“ and unclean and more like a quick mockup for something that was created by a 6 year old with crayons. Of course there are exceptions here as well and also many desktop and mobile applications where a lot of time and effort was put into the design by people who know what they are doing, but unfortunately the opposite is still too often the reality. Bright UI designs, on the other hand, often do not have these problems and usually appear much cleaner, clearer and more “crisp“, at least if they have been developed with care and a good choice of colors. There are also bad results here, for example when far too many gray-like colors are used and the appearance is more in line with the first graphical operating systems than a modern surface, but on the whole light themes can be designed much better and more finely granulated than dark ones.

The wish that Nord should also be available as a light theme arose very early on in the project, but the focus at the time was clearly on developing new ports and improving those that had already been released. I had the plan for this very early on, so I was very happy that the community saw it the same way. However, the focus was initially elsewhere and with the ever-growing popularity, at some point it was impossible to start this very big topic due to the enormous amount of time that was necessary to be spent on other topics. The goal is therefore to start the development of a light “day“ theme mode when the topics described in the sections above and the “Road to 1.0.0“ are completed.

One of my absolute favorite knowledge sources for UI and generally digital design is “Refactoring UI“. It is developed by Adam Wathan (@adamwathan) and Steve Schoger (@schoger), the makers of Tailwind CSS, who are very experienced designers and whose knowledge I use to as main inspiration for my projects.
Of course, this also applies to Nord and I have often tried to clarify this in relation to the light “day“ theme mode development. As soon as this huge topic can finally be started properly there will be more details, but I don‘t want to leave the topic unaddressed and want to use it to refer future inquiries to this section.

ItzSwirlz · 2023-02-19T00:30:06Z

ItzSwirlz
Feb 19, 2023

That was.. a lot, and I read about 10% of that, but I am all for https://github.com/ItzSwirlz/nord-lapce to be moved into the new @nordtheme-community

1 reply

svengreb Feb 25, 2023
Maintainer Author

This is also currently on my private port idea list that will be made public within the next weeks as a GitHub project board in the nordtheme .
A concept how to prioritize and decide on the way how community ports can be created in the @nordtheme-community organization is something I need to work on, but I guess Lapce could be something that might also be an official port. It looks like the theme API is not too complex and exposed as YAML/JSON DSL so there is no need for me to learn a new language like e.g. for ports like the one for Emacs.

gearsdigital · 2023-02-19T12:03:54Z

gearsdigital
Feb 19, 2023

I highly appreciate your hard and quality work and I know how much effort and heart blood you put in your projects. I simply can't grasp how the fuck you find time to write such an insane long text 😅 I mean, who has even time to read through all that?

Anyhow, let me now if I can help you out. But please don't ask for proof reading 🥶

1 reply

svengreb Feb 25, 2023
Maintainer Author

Thanks 💙
Sometimes it‘s rough to make sure this quality, but most of the time it is fun 😄
My task tracker counts round about 183h for this text and the overall roadmap planning, but it also says that the task creation time is 1.1y ago so all of this was done one step a time. Many tasks are also just plans and I only start to work on it “when I reach the bridge“ 😛
I will definitely take up your offer of help for some planned tasks!

SamG06 · 2023-02-20T05:59:10Z

SamG06
Feb 20, 2023

Found this project via Milkdown the other day.

Love the work! Looking forward to where Nord leads. Definitely will be my go to in future projects. Hope I can help here and there. 😎 👋

1 reply

svengreb Feb 25, 2023
Maintainer Author

Thanks, it‘s always nice to see, and a great motivation, when a project is so well received 💙
I also have Milkdown on my task list to see how it can be included in upcoming documentations about projects that adapted Nord as a first-class theme, or even build exclusively on top of it, and make it easier for users to see where Nord is already, next to official ports, available out-of-the-box

cassidoo · 2023-02-23T22:51:25Z

cassidoo
Feb 23, 2023

Major kudos on the work you've put into this so far, this post was wildly long but I respect the effort and care you're clearly giving to the project, looking forward to seeing more!

1 reply

svengreb Feb 25, 2023
Maintainer Author

Thank you, feedback like this means and motivates a lot 💙

bmadone · 2023-03-13T20:00:44Z

bmadone
Mar 13, 2023

The theme is amazing, I check my issues that I opened months ago, and now everything is fixed, thanks!

0 replies

bfg-coding · 2023-04-05T20:01:55Z

bfg-coding
Apr 5, 2023

So something I couldn't get a clear answer is what is the licensing with all this? I'm chatting with the DaisyUi maintainer about building a nord theme for them but they were concern about licensing. Sorry if I missed it in your update here but I'm curious could you give a clear answer on what is licensed and how it's licensed?

Thank you for your time and effort I have loved using this theme on all my code editors for a consistent feeling and planning on making it the theme for my linux machine I'm working on.

2 replies

svengreb Apr 5, 2023
Maintainer Author

Nice to see you enjoy using Nord 😄
The licensing model did not change and still uses the MIT license. Licensing a combination of 16 colors with something different would be… ridiculous 😅
I guess your question is targeted to the author's concerns in saadeghi/daisyui#1736 (reply in thread), but this is about trademarks. The name "Nord" is just the German word for "North" and is a normal word in dictionaries so there is nothing related to trademarks in any way. In the end the whole Nord project is more or less a "one-man's open source non-commercial show" and there is no kind of company or something similar behind it.

bfg-coding Apr 5, 2023

Thank you for the quick and concise answer. I appreciate it and look forward seeing all the places this project goes 😁

davidlohyna · 2023-07-01T11:55:16Z

davidlohyna
Jul 1, 2023

Hey Sven, thank you for all the fantastic work you have put into the Nord project and the post regarding its direction.

I have been enjoying the Nord theme for Vim in my iTerm for quite some time now, and I would be happy to help you maintain the project. I am not a seasoned programmer by any means, but I am in the process of learning. I am passionate about open-source software and willing to learn what it takes to contribute.

Please, let me know if there is anything I could help with. I noticed a few minor mistakes within the post, so that could be a start, I guess, but I am eager to contribute on the code level or in other ways.

0 replies

coxde · 2023-09-18T23:55:15Z

coxde
Sep 18, 2023

Hi Sven, just want to thanks for all your stunning work and sharing your experience with this article. I'd like to help with this project if there's anything I could do!

0 replies

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Nord

Northern Post — The state and roadmap of Nord #183

{{title}}

{{editor}}'s edit

{{editor}}'s edit

Replies: 8 comments 6 replies

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

Select a reply

Northern Post — The state and roadmap of Nord #183

svengreb Feb 18, 2023 Maintainer

The History of Nord #

Origin #

Design Inspiration #

Sixteen Out Of Millions #

Polar Night #

Snow Storm #

Frost #

Aurora #

Naming #

Underestimated Importance Of Color Themes #

Growth #

Initial Project Features And Structure #

The Beginning Of Port Projects #

Public Awareness #

More Ports, More Time #

Beyond But Also Within Personal Use #

Today‘s Scope #

Behind The Scenes #

Identity & Branding #

The (Single) Human #

Branding And Its Drawbacks #

Work-Life Balance #

The Desire To Be “Doctor Who“ #

Working in Public #

The Ecosystem #

Nord‘s (No Longer So) New Home #

The Wide Variety Of /r/nordtheme #

Real-Time Conversations… #

…And How They Will Evolve #

The State Of Things #

Keep Things Up To Date #

Help Users To Make Thinks Working #

Push Things Through Quality Gates #

Quality Comes With Time #

Quality Is In The Details #

Public “Early Access“ #

Sponsoring #

How I Feel About Sponsorship #

How You Can Become A Sponsor #

Where Your Help Is Used #

The Future Plans #

Development Focus #

More Fluid And Automated Workflows #

Tools Are Key #

Finally Complete The Move To The New Home… #

…And Tidy It Up #

Feel More At Home #

Nord‘s New Home On GitHub… #

…With Central Project Planning And Issue Management… #

…And A Space For Community Creations #

Catching Up On The Backlog #

The Home Of The Community #

GitHub “Discussions“ — The Long-Desired Solution #

Real-Time Communication — Welcome To Matrix & Discord #

Fill The Blog With Life #

Make Better Use Of Existing Platforms… #

…But Also Say Goodbye To Some Others #

Retire Arctic Ice Studio As Nord Brand… #

…And Put More Focus On The Human Behind It #

Building A Dedicated Infrastructure #

Road to 1.0.0 #

A Look Into The Distant Future #

A Bright Future — Light “Day“ Theme Mode #

Footnotes

Replies: 8 comments · 6 replies

svengreb Feb 25, 2023 Maintainer Author

svengreb Feb 25, 2023 Maintainer Author

svengreb Feb 25, 2023 Maintainer Author

svengreb Feb 25, 2023 Maintainer Author

svengreb Apr 5, 2023 Maintainer Author

svengreb
Feb 18, 2023
Maintainer

Replies: 8 comments 6 replies

svengreb Feb 25, 2023
Maintainer Author

svengreb Feb 25, 2023
Maintainer Author

svengreb Feb 25, 2023
Maintainer Author

svengreb Feb 25, 2023
Maintainer Author

svengreb Apr 5, 2023
Maintainer Author