About (FAQs)


Contents

Glimpse is an open source image editor based on the GNU Image Manipulation Program. The goal is to experiment with new ideas and expand the use of free software.

Introduction

Technical Questions

Project Governance


What is the correct name for your project?

The free software we produce is called “Glimpse Image Editor”, but we sometimes shorten that to just “Glimpse”. We refer to our governance structure, core contributors and participants on our public Matrix channel as “the Glimpse project”. We often call our social media followers, donors and end users “the Glimpse Community”.

If you are a blogger or a member of the technology industry press, we do not yet have branding guidelines in place. However we have provided screenshots, our branding assets and instructions for their basic usage here: https://github.com/glimpse-editor/branding

Return to top

Did you know that name is used elsewhere?

We are aware of a number of other unrelated projects called “Glimpse”. We have made changes based on feedback from our critics such as changing our website’s domain name and defining “Glimpse” as a shortened version of “Glimpse Image Editor”.

The project’s current stance is that while we are theoretically open to changing our name, there is very limited support in favour of actually doing so. We granted our critics time to find an alternative name that addresses the concerns they raised, fulfils our project’s requirements and enjoys popular support. Even with three months and our assistance they were not able to do so, so we consider the matter closed for the time being.

See “How does your project govern itself?” for more details about why we now limit discussion about this topic on our Matrix channels.

Return to top

What is wrong with the “GIMP” name?

It was originally chosen by Spencer Kimball and Peter Mattis as a joke name that refers to a questionable scene in an 18 certificate movie called “Pulp Fiction”. Within Linux enthusiast and hobbyist communities that whimsical ‘90s era “gross out” humor may still be appreciated by some people. However, like all “comedy”, there is a time and a place for it.

We also believe that the casual ableism of the name is unwelcome, and it hinders efforts to expand participation and diversity within the free software community. That means the project could be missing out on new ideas, contributors and resources that would improve things for everyone.

Many of us have real world experience advocating free software as a serious choice in educational or workplace environments, and we believe that a joke name some find offensive and distracting presents an unnecessary obstacle to wider adoption.

Return to top

Why are you forking?

We do not believe that upstream’s suggestion to “expand the acronym” to fix their software’s name adequately addresses the problem, and after 13+ years of users repeatedly asking we think the most constructive path forward is to fork the project.

In addition, the dedicated UI design team for GNU Image Manipulation Program stopped meeting in 2012. We feel that, as a result, usability improvements seemed to slow down for the better part of a decade, and that was an area that needed more attention.

Finally there was a historic decision to remove the third party plug-in registry and in-built mechanism that supported it. While we lack the resources to reinstate that system, we can pre-bundle useful third party plug-ins that are difficult to find and install.

Return to top

Are you just forking because of the name?

No, but it did provide the motivation for many of us to fork the project in the first place.

Our contributors have used GNU Image Manipulation Program for a long time, but the upstream project only has finite resources and so has to prioritise some changes over others. Decisions may have also been made historically for sound reasons that need to be revisited but cannot for the same reason. This can mean that good user interface improvements and functional changes that the community suggests can go unaddressed for years.

What this project aims to do is inject some new ideas, energy, contributions and money into a tool that most of us take for granted. We also want to expand the adoption of a great piece of free software.

Return to top

What if I find the word “Glimpse” offensive?

That seems unlikely given we checked its meaning in every known language, but if you have a legitimate concern then let us know.

If you are offended by the fact we renamed the project, we suggest you continue using the GNU Image Manipulation Program instead of annoying our contributors and making more work for our moderators.

Return to top

Do you intend to replace the GNU Image Manipulation Program?

No, this project does not intend to supplant the GNU Image Manipulation Program. You may have noticed we already link to their donations page throughout our documentation and we periodically donate a portion of our own funds to the upstream project.

The Glimpse project is also run entirely by passionate enthusiasts. Development on the GNU Image Manipulation Program will continue as normal with same core group of developers and be entirely unhindered by this project.

We anticipate in the coming months and years that Glimpse will be a place where people can experiment with fixes that upstream may not have had the resources to work on and new ideas that upstream may have felt unable or unwilling to try for legacy reasons.

If we come up with some popular improvements that really enhance the user experience or fix bugs that impact both projects, then we would assist with contributing them back upstream so the wider community can benefit.

Return to top

Is forking the project a duplication of effort?

No, because there are at least three well-articulated problems that justify our fork existing.

From our point of view we are simply exercising our software freedoms by forking the project and redistributing a modified version for others to benefit from. This is fully in accordance with the spirit and requirements of the GNU General Public License and GNU Lesser General Public License as they both apply to this project.

There are early plans to write a new image editor with more modern technologies in parallel to our current efforts, but that will take a number of years to produce.

Return to top

Which operating systems do you support?

We support systems running Windows 7 or newer, and modern variants of GNU/Linux.

Unfortunately we are not able to support MacOS at this time, but that is planned for the future. For the time being, we recommend using Seashore as an alternative.

Return to top

Can I install Glimpse and GNU Image Manipulation Program on the same machine?

On Windows, you can safely install and run both applications at the same time.

On Linux, the Flatpak build that we support and maintain is fully self-contained and should not interfere with any installed versions of the GNU Image Manipulation Program. If you discover that is not the case on your system, please report it as a bug.

If you are using a Linux build from a third party source that we do not directly support (such as Snapcraft, AUR or your distribution’s package repositories) then it is unlikely because there may be package and file name conflicts. You should ask the people responsible for maintaining those packages for confirmation and any help you might need.

Return to top

Are you going to publish this for my favorite Linux distribution?

You can see all the Linux installation methods we are aware of for Glimpse Image Editor on our downloads page.

We directly support a Flatpak on Flathub, and we plan to publish our own AppImage very soon.

The Glimpse project does not endorse or “prefer” any specific packaging format or distribution. We have limited resources, so have chosen a primary format (Flatpak) and a fallback format (AppImage) as they are straightforward for us to maintain over a sustained period and will have wide compatibility within the Linux ecosystem over the next few years.

However, we support and encourage third party packagers wherever we can, and code changes that facilitate their work are accepted. An excellent example of that policy in action is the Snapcraft package, which is managed and maintained by Heather Ellsworth.

An alternative example is an individual that has not been in direct contact with our project at all maintaining a community package on AUR for Arch Linux users. Unlike our official releases it is built from our development branch instead of formal release tags, so we do not accept any bug reports from users that have chosen to install Glimpse Image Editor using that method.

At the request of package maintainers, we plan to provide a source tarball we have run make dist against from Glimpse Image Editor 0.1.2 onwards.

Return to top

Will you support BSD, Haiku, Solaris or other UNIX platforms?

The only UNIX operating system we currently have plans to directly support is macOS.

Other UNIX systems are treated the same way as any individual Linux distribution. We do not directly support the individual packaging formats and publishing platforms for each variant of UNIX because we don’t have the knowledge or resources to support and maintain them all.

However, we will accept code fixes that enhance UNIX compatibility and will assist any third party package maintainers that want to port Glimpse Image Editor to operating systems like BSD, Haiku, Solaris and other UNIX variants.

Return to top

Will you contribute changes back upstream?

Absolutely! We intend to be good free software citizens, and as soon as we have made changes that the upstream project want to include in their codebase we will be willing to assist them however we can. We have also periodically donated a portion of the donations we have received to the GNU Image Manipulation Program developers.

While both projects may not agree on some things, it is clear to us that an adversarial attitude will not help either of us. If we work together then the whole free software community can benefit from this fork that attracts new contributors, breathes new life into an ageing codebase and shares free software with a whole new audience.

Return to top

This project is big! Will it take a long time to rebrand?

The 0.x releases fork the GNU Image Manipulation Program v2.10.x. These initial versions focus on re-branding, tweaking the existing UI, fixing upstream bugs and improving Windows support.

The 1.x releases will fork from GNU Manipulation Program v3.0.x.

The 2.x releases will use a brand new GUI we have written from scratch while still relying on the underlying GEGL and BABL libraries that GNU Image Manipulation Program does. That effort will take a number of years, so this will be worked on in parallel while we continue with the 1.x releases.

We have been pleased by the positive feedback we have received from our userbase so far, and our contributors’ dedication continues to help us progress the project faster than anticipated.

Return to top

How does your release numbering work?

Odd number versions (eg. 0.1.1 or 0.1.99) are “in development” and even-number versions (eg. 0.1.0 and 0.1.2) are stable releases we take the time to beta test.

We follow a “tick-tock” release cycle. 0.n.0 “tick” releases re-base on the latest upstream version, and 0.n.2 “tock” releases refine it.

That means for example that Glimpse Image Editor 0.1.0 and 0.1.2 are based on the GNU Image Manipulation Program 2.10.12, but Glimpse Image Editor 0.2.0 and 0.2.2 will both be based on the GNU Image Manipulation Program 2.10.14.

The benefit of this approach is that we know when someone reports a bug to us if they are running a stable or unstable release of our software. We also have the the option to add more than one “tock” release for the same “tick” if we think that would be beneficial.

The downside is that we will usually be a release or two behind upstream, but we believe that is worthwhile because it gives us time to make our own downstream changes. Also it ensures that versions of the GNU Image Manipulation Program we base on have already been tested in the real world before we start using them.

Return to top

When are you going to implement the bug-fix or feature I asked for?

The first place to check is our Github Issues list.

We aim to tag each bug and feature request to a release milestone so that you have a rough idea of when we think we can feasibly deliver the functionality. Those estimates are subject to change based on our shifting project priorities and any technical hurdles we come across. We also do our best to add regular comments to every issue so that you can see the most up-to-date information about them.

If the functionality you want is not listed, the next place to check is the roadmap page for the GNU Image Manipulation Program. Because that project has more contributors and resources than we do as a downstream fork, we are normally a release or two behind them. If they are implementing a fix or change though, then we will eventually inherit it.

Finally, if the change you want isn’t requested in either place then feel free to raise it as a bug or a feature request! Alternatively you can contact us by using the links on our Contribute page.

Return to top

Why are you using Github instead of Gitlab?

That was a choice made early on for entirely practical reasons such as project discoverability, ease-of-use, user familiarity and cost.

As a project we are aware some people have ethical concerns about using Github, and that other projects appear above us in the search results. For those reasons we periodically discuss how our contributors feel about using it, as well as the merits and drawbacks of potential alternatives.

There are no immediate plans to move our code, but there are early plans to host a separate code mirror for use with our build system.

Return to top

Could you just run “find and replace” to fix the name?

We could, but that would completely destroy plug-in compatibility and break the upstream subcomponents on which we rely. That would also cause serious problems with all the build scripts and be very time-consuming to fix.

To preserve compatibility we had to maintain existing file names, variable names, constants, class names, methods and APIs. This meant we had to provide our own files, variables and constants, then identify where we wanted to use them, swap in those values wherever that did not break compatibility, and find a suitable replacement wherever we referred to upstream code that we had not modified (we settled on “GNU I.M.P”). That cannot be achieved by just using find-and-replace tools or regular expressions.

In addition to changing the name we also wanted to change the project logo. We commissioned an artist to do that for us, and subsequently had to make code fixes to the application to swap in our own art assets.

Finally, we also had to ensure that our changes were applied appropriately in the existing translation files and did not break the automated mechanisms in the build systems that keep them up-to-date.

In short, it is not easy to rebrand the GNU Image Manipulation Program. Similarly, the reason why this project is not just “one man and his Github repository” is because we do have other objectives and intend to create free software that other people actually want to use.

Return to top

Where is the Glimpse code of conduct?

You will find it on this page. Our code of conduct is based on the contributor covenant and will be developed and amended over time as the need arises. As this project spawned from the fediverse our experiences in that online space are going to inform the project’s future governance and direction.

There is no benevolent dictator for life in the traditional sense for this fork because we believe in the merits of collective decision-making. They might sometimes take longer to make decisions, but a group is often less fallible, makes better-considered choices and reflects the will of the wider community more accurately than an individual.

That approach has worked well for us so far, and you can read more about our governance structure here: “How does your project govern itself?”

We also want to make it clear that we value and encourage diverse representation in leadership positions within our community, and we believe that is the best way to enforce a code of conduct that protects all contributors and promotes wider participation. At this early stage our initial governance team is formed entirely of individuals from marginalized communities, and that makes our project very atypical. That emerged organically as a result of the project starting on the fediverse.

We know how important it is to enact the right code of conduct and enforce the rules pro-actively. We want to promote a safe and inclusive environment, not a toxic one. If you have ideas to help us do that and want to get involved with this discussion then please join us in the project’s communication channels.

Return to top

How does your project govern itself?

The way we govern ourselves is something that evolves over time based on feedback we receive and what we find works and does not work. The summary provided in this answer is intended to illustrate how we currently make decisions and are held accountable by our community.

Github Issues are used to track bug reports, suggestions and questions from the wider community, and items we have agreed as a project need action. Action items are allocated to a milestone to give an indication of their priority and likely timeline, but these are always provisional until the work is done.

Most day-to-day discussion happens in the #glimpse:matrix.org (or “Glimpse Community”) Matrix channel. Anyone can join so long as they comply with our code of conduct, support the basic premise behind this project existing and don’t spam the channel with off-topic chatter or shameless self-promotion. This is where most of the actual decision-making happens, and our community has the opportunity to voice their opinions or share their domain-specific knowledge there.

Anyone named in the AUTHORS file are eligible to join the #glimpse-contributors:matrix.org (or “Glimpse Contributors”) Matrix channel. They make the low-level technical decisions necessary to deliver items that have already been agreed. It is also used as a fall-back communication channel between contributors when the “Glimpse Community” Matrix channel is busy with the decision-making process so that development work is not obstructed by it.

While they might make some time-sensitive moderation decisions as individuals, all other decisions are not considered “agreed” until they have been discussed on the “Glimpse Community” channel and a consensus has been achieved between all members of the “governance team”. Initiatives originating from the governance team instead of the community are sometimes discussed on the “Glimpse Contributors” Matrix channel first.

No decision is ever set in stone and can be revisited if new information comes to light or there is enough support within the project to do so. The governance team will generally only block the re-opening of an issue or delay a decision if the discussion is becoming too heated or obstructs the day-to-day running of the project.

There are currently four people in our governance team: Bobby Moss (started the fork), Christopher Davis (posted the renaming issue on upstream gitlab repository), Luna (started the “UI rewrite” planning) and chaomodus (manages our server-side infrastructure).

Finally, the project may from time to time run polls on social media to canvas opinion for specific issues if there is support for doing so. They are always non-binding and only intended to facilitate the existing decision-making process.

Return to top

What are all the Matrix channels for?

All of our channels are on matrix.org. You can get access to the invite-only channels by asking for it on the “Glimpse Community” channel.

Return to top

Why do you need monetary donations?

Just like many other free software projects we need to host the collaboration tools we use to develop and share the project. We have to purchase domain names, cloud servers, code signing certificates and subscriptions from service providers to make this project a success. In addition we also intend to pay the artists we commission for the re-brand, market our software, and eventually help our contributors represent us at conferences.

If you would like to donate some money to Glimpse project, you can do so by donating on Open Collective.

We also encourage those who want to support the GNU Image Manipulation Program to use their donation page to do so.

Return to top

How do I stay up-to-date with this project?

You can follow us on the fediverse and Twitter. This blog also has a full text RSS feed. We also recently setup a Facebook page.

Our Open Collective backers also get regular updates about the project. Our more in-depth daily discussions can be viewed on Matrix.

Return to top

How do I contribute to this project?

All of our contribution links are available on our Contribute page.

Please ensure that you read our code of conduct before you join our community. Regardless of your past experience and the usefulness of your contributions you are expected to comply with it.

Return to top