LXDE and Calculate Snub GNOME 3

A little GUI toolkit news, courtesy of some links from a reader…

PCMan has created what looks like a qt fork of PCManFM, and there are some indications there and elsewhere that other LXDE components may be moving in that direction.

PCMan does great work in the lightweight FM area – you can thank him for SpaceFM, as it was built from the legacy PCManFM as a base. However, it should be noted that the current incarnation of PCManFM is based on gvfs/udisks, with all their incumbent issues and GNOME dependencies. This is something which PCMan never liked, and likes even less now that he sees how they perform, so I wonder what he has in store. I know he’s already working on a fuse-based udisks replacement. Yet the rewrite probably got the code in better shape for a qt transition. Will be interesting to see what comes out of that camp.

Also, the Gentoo-derived Calculate distro has announced for their latest 13.4 release:

GNOME3 is no longer supported, as CLDG now features GNOME 2. We’ll not be supporting Gnome in next versions.

This seems like a mass lightweight (if I may combine those) migration away from GNOME3/GTK3, which is clearly being developed in a corporate/hostile-to-free way these days (background). Good for them! Hopefully this spells longer-range support or a viable fork of GNOME2 & GTK2. I’m of the opinion that GNOME3 should have been a fork, not a new major release version of GNOME, as they covered a great public park with concrete.

I’m personally watching these GUI toolkit directions carefully. qt doesn’t excite me much more than GTK3, but its probably somewhat better than what Red Hat has planned. I’ve been toying with the idea of a flexible GUI engine of sorts, perhaps to gradually and eventually replace SpaceFM’s GUI, and take it to the next level. But I’ve been stopped because I don’t like the toolkits available, and things seems so volatile. (It’s not pleasant to invest hundreds of hours on a toolkit, and base software on it, only to have it turn to sand under you.) Perhaps at this point a multiple toolkit framework is best, but that still represents an investment in a particular API.

Linux is really hurting in this area – hard to develop anything decent without wasting your time rewriting the GUI every other day. I’m glad I did SpaceFM as a prototype rather than investing a full design in GTK, but in some areas it’s ready for some new components to allow it to grow, yet I’ve been hesitant to write them in GTK. Overall I would like to break away from Red Hat/GNOME now that they’re poisoning the GTK well, but not sure that qt is for me either.

Why Do It? The Motivations Behind Free Software

I have been developing free software for a long time, originally as an independent freeware author in Windows (oh the stories I could tell you there) and more recently in Linux. Why do it? And what are the values and principles that are most functional when working for free? I thought I would take some time out to share the strategies I have developed over the years that make this work.

First, why do anything for free? I think this is a core question to address before even contemplating working for free. My answer to this is that I don’t really believe that money as motivation works to the benefit of humanity. That system, which in my world is a relic of the past, leads to exploitation and corruption. The people who make the most money in this world typically do the least work, certainly the least beneficial work (usually exploiting people, other life forms, and the environment). Work produced based on the promise of financial reward is increasingly of low quality, designed to fail, and primarily seeks to make more money and create dependence. Any money made (usually most of it on the corporate level) is further used to enslave and exploit, as well as to destroy the very planet we depend on for life. (Do you know how many products are designed to fail after a period of time, and thus need to be manufactured again and again, just for the sake of profit?) I think if humanity is ever to eliminate poverty, exploitation and environmental suicide, and provide real means for people to better themselves, the money system has to be replaced, and that has to begin somewhere, and soon. I believe some approaches common in Linux are good examples of what community-based effort can produce. Regardless of your financial standing, you can download great software, learn and grow. Being a contributor to that community has many rewards, immediate and also in terms of long range dreams of what is possible.

Most of us come from cultures that aren’t based on free contribution and availability, and are based in competition, so some adjustment of values and motivations is necessary to work effectively in such a community. Especially professional software developers are accustomed to being very well-paid for their time and efforts. I find that if they bring their normal motivations and values with them into the free community, they wind up feeling resentful and frustrated, and so do their users.

Software development involves hard work and real effort. I love getting creative on the computer, designing good tools and innovating, and that is my primary motivation – to make something cool. A painter loves to paint – just try to stop him from painting! I share some of my work as public projects as a way of giving back to the community and contributing to the growth of Linux. Yet even the most fun creative project involves drudgery – chores which need to be done to make the overall project polished and usable. Further, for software to be more than just someone’s mostly-broken pet project (which if you’re lucky, you can even build with the instructions provided), it requires continuous efforts in publishing, support, documentation, web site maintenance, forum participation, etc. At times, it’s simply a LOT like work.

When people come to this work from traditional employment-based backgrounds, they tend to become resentful and quickly disillusioned. Normally they would keep thinking of their coming paycheck or their needs as a source of motivation, but there is not much pay involved in free work. If you think you will get rich off of a popular Linux project, guess again. While some developers manage to scratch out a living from donations, and corporations exploit it in the business environment, in general donations to developers are rare events, at least in my experience. My donations page has received only a handful of donations in the past year, despite thousands of people using my software daily. My software is offered genuinely for free, so I don’t have high expectations in this area – it’s a treat if a donation comes in, but I mostly avoid resentment at the tip jar being ignored. But if your motivation for doing the drudge work is money, you can easily begin to feel misused, unappreciated, ill-treated, and enslaved. You begin to ask, “Why am I devoting hundreds of hours to this? Why am I investing my time and energy?” This resentment can easily build until it paralyzes your work, and you forget your original reasons for creating it.

Simply put, the motivations for doing free work need to be different, because the conditions are different. In some cases, your expenses of maintaining servers and so forth can exceed what little income exists. If you depend on monetary reward, you’ll be disappointed. Further, there is little reward for success. Even if your project becomes hugely successful and gains many thousands of users, your ‘profits’ don’t increase much, while your workload does! More users mostly mean more work in terms of greater activity, bug reports, feature and support requests, etc. (I originally almost decided not to release SpaceFM publicly, expressly because I knew it would be popular.) Yes, it’s gratifying to see people appreciating your work, and knowing that you’re contributing something useful. This can be a little ‘ego boost’ to help push the work forward, but it’s not very tangible, and won’t feed you. Also, even if you make a great piece of software, it may never get much recognition or use – you won’t have much of an advertising budget. So pats on the back may be rare even for the finest work – don’t depend on them for motivation.

Beyond this, while most users are appreciative and often take the time to give you a ‘thanks & well done’, not all users will make you happy. You’re dealing with the public, and this can take patience. A few users will even be obnoxious and rude. Back in the days of Windows freeware, I even had a user threaten to sue me, alleging installation of my software broke their system. Despite all the helpful and kind users, just a few negative experiences can cause real resentment toward ‘the users’, especially if your skin hasn’t thickened yet, or you’re already feeling resentful at working for free.

Because of some of these dynamics, people often believe that ‘free == junk’. If it’s for free, don’t expect my product to be of high quality. You’re lucky to be getting anything, so don’t expect excellence in something that is offered for free. Yet this is a trap, because it’s no fun producing junk. It’s much more rewarding to take the time and effort to produce something that shines and really works well. Yet a resentful developer won’t want to make that investment, and thus will not reach that rewarding state of accomplishment.

Sounds pretty bad at this point, doesn’t it? Hard to imagine why anyone would work so hard and put up with the hassles without monetary compensation. Yet actually I find free software development very rewarding, and that is why I have done it for so long. It’s all a question of motivation, and there are some unique rewards not found elsewhere.

Motivations That Work For Free
As I said, my primary motivation, especially in a larger project, is to make something cool – something that demonstrates excellence and innovation. Why? Simply because a painter loves to paint, and paint well. Also, genuinely serving people is always rewarding – it’s a human thing, we want to help, to contribute. Making junk is not rewarding, especially on a personal level. (Even when people work for money this is true, which is why much employment is un-gratifying.) Taking the time to dot the i’s and cross the t’s, and produce something that is genuinely useful and reflects my creativity and attention to detail is something which I have come to know as personally very rewarding, and that is motivating. This is my art, in a sense – I want it to be excellent.

Much falls out of that primary motivation. For example, I see bug reports, negative feedback, and feature requests in this light. These people are contributing to the project, helping to make it better. Often users are almost apologetic for reporting bugs or making requests with free software – they too suffer from a sense that they are merely asking for something for free, that they don’t deserve it. They will often be surprised when I thank them for a bug report or request, and say, “No, I should be thanking you.” Thank me, sure – I’m contributing – but so are you. I encourage users to contribute in these ways because just as my work helps to make the project excellent, so does such input from users – it is essential, in fact. Especially when software is free, the user is the whole reason software exists – the user is its reason for being. (Ironically, commercial software forgets this, as its reason for being is to make the developer or his/her boss the most money.)

As developers, we often spend time fixing bugs or implementing features that don’t affect our personal use of the software. Working for free, this too can build resentment. Why am I spending my free time working on this aspect that doesn’t affect me? Yet I look at this from the higher perspective of what serves the software, what helps to make it the best it can be (within what I’m willing to invest). Users may not view it this way – they may just want a feature or bug fixed for their own use. Yet I review bugs and requests with an eye toward how they serve the software, and by extension the users (who again are the whole point it exists). So contribute to the software by making reports and requests, yet remember not to make demands, which are not appropriate in a free context. At any rate, I never view them as demands, even when they are worded imperatively – to me they represent people making contributions to the software in the form of feedback and ideas. Thus I appreciate what another developer may discourage or resent, because I remember to set myself free.

Beyond the ‘make something cool’ motivation and rewards, there are many perks to free software development that can create an entirely novel context of what ‘work’ means, making it a very enjoyable process, and washing away some of the stains of exploitation which we all carry. In this sense, contributing to free projects can be liberating in unequaled ways. I still have to continuously remind myself of some of this, and remember to take this perspective, as it’s easy to fall back into conventional modes of thinking.

The Perks
Working on anything free, it’s important to assert your rights. Working for a boss, one is at the mercy of another – told what to do with one’s time and efforts, often working on things one disdains, at times when you’d rather be doing something else. This creates an atmosphere of misery, and many developers bring this atmosphere with them to free development. They are in this habit of being driven by others’ demands, so they view users and ‘co-workers’ as telling them what they have to do. This is why developers often get so cranky at bug reports – they’re being handed more work, demands! Eventually, when you’re not being paid, this can spell deep resentment. Even I fall into this trap sometimes, until I remind myself that there’s nothing I have to do!

As a free software author, my time is my own, and I’m my own boss. This is especially true because I tend to be a one-man band, not usually contributing to larger projects that incur expectations and timelines. And because I’m working for free, not working has no financial consequence – in that sense it’s even freer than being your own boss in business. If at any time I feel “I don’t want to be doing this”, I simply walk away from the computer, or put those files away for now. This means that my work is not a product of misery, of me forcing myself to do something at a time when I’d rather be doing something else. If I’d rather be doing something else, I do it! Thus when I am working on the project, it has my natural attention and motivation – I’m interested and engaged, enjoying the work. I think this contributes to its quality – it becomes a labor of love.

You might think I’d never get anything done under those conditions, but in fact it’s natural work for me, and at least some of the time I want to do it. I would like a bumper sticker: “I’d rather be working on SpaceFM“, because I really enjoy it. And when I stop enjoying it, I quit it for the moment. If I stop enjoying a project routinely, I quit it entirely. Of course, there are chores and drudgery involved in anything useful, aspects of the work that I can’t say I would prefer to do. But if they are a necessary part of something I want to add or make more functional, then I am willing to do the chore because I want to achieve the larger goal. Overall the process is still one of enjoyment. It’s sort of like cleaning your house or fixing your car – you may not actually ‘enjoy’ vacuuming per se, but you enjoy having a clean house to live in or a car to use, so it’s a necessary ingredient of a larger joy. Thus I do manage to get most of the chores done, often promptly, because I want the enjoyable result – the rewards. So in a sense you do work for rewards, but the primary reward is no longer money.

You may notice that I rarely involve myself in estimates of when something will be done. I may speak of general plans, and things coming up soon, but as a free software author I simply don’t do deadlines – they run contrary to my way of working. When selecting what in a project to work on next, I do consider what most needs attention, but I also consider what I simply feel like working on at the time. Sometimes I’m more in a mood for coding, or web site maintenance, or just answering questions and chatting about potential improvements. Other times I don’t feel like working on it at all, sometimes for extended periods, so I don’t. While bug fixing is usually a chore, sometimes I’m sufficiently motivated to knock a few bugs off the list – that too can be rewarding, and I know it serves the software. If I’m going to produce something of quality, bug-fixing occasionally needs to be done – it’s part of the ‘job’. If I don’t want that job, I wouldn’t share the project publicly in the first place, or would drop it.

I also almost never accept bounties, or promise to do something if a particular sum is paid on delivery. You’ll note that my donations page reminds you that “donations are not associated with feature requests, but feedback is always welcome”. I view donations as a ‘thank you’ and as general support of me and my projects – and it does boost motivation when I see a donation roll in. Just because a project is available for free doesn’t mean you can’t pay, it just means that your forms of contribution are voluntary too (and not all involve money). It does feel good to get some cash, as any developer will tell you. In fact it tends to be all the more appreciated, because you know it wasn’t required. But I find making promises to do something for pay interferes with my way of working on free projects, so I mostly avoid bounties. No one can effectively force or pressure me to do anything in this area, and I like that freedom. It’s one of the perks of free software development – guard it.

This may sound like over-analyzation of motivations, but it’s important to get and keep your head straight on these issues, as it makes a huge difference on a day-to-day basis, because it is a lot like work. Because I don’t really force myself to do anything, no one else can successfully force me, and I know that I genuinely want to be doing what I’m doing. Part of managing this level of freedom in time involves good project management. I need to be able to let some things pile up without losing or forgetting them. In addition to issue trackers, I use casual (usually downright messy) lists to remind me where I left off, what high priority items are pending, etc. So when I am able and in the mood to devote a few time clicks to the project, I can choose wisely where they’re spent.

I tend to like things to work right! I want to achieve a level of excellence – it’s rewarding, and I take it personally when it fails. I feel that if I’m going to publish something, basic support is part of that effort. So it’s hard for me to leave things go that ‘should’ be addressed – this is actually something I have to work at, letting things go. Yet if I don’t, the ratio of users to developers will overwhelm me, I’ll burn out, and I’ll become resentful of the work. It may only take a minute to add a bug report or feature request, or even to throw something on a list myself, yet each of those items can take hours to address. Thus the TODO lists and open issues tend to grow faster than items are removed. This can be discouraging if one doesn’t take an effective approach.

I do NOT accept “If it’s free, excellence doesn’t apply.” I believe working toward excellence in any product is the whole point, and rewarding. Yet there are also realities of time and will, and if you don’t work effectively with what is available, you’ll burn out or lose motivation for the project entirely. Thus a balance needs to be achieved between the desire for excellence and the investments one is willing to volunteer. If not, a free project will become sidelined or ignored. And this too is okay – as a free author there really is nothing you have to do.

Another perk to free software development, and a good routine reminder: it’s my program. This is my software and I’ll do what I want with it. I’m the captain of this ship, the benevolent dictator. Others can offer suggestions and even judgments, but the decisions are mine. The reason this is important is that often without meaning to, some users can become very pushy, applying pressure to a developer’s inclination to make things work well. Usually they have their own vision of the software, or they’re having problems which they feel ‘should’ be fixed. Perhaps they have a sense of quality and want things done ‘right’. Whatever the reason, in some cases people can become almost hostile in their attempts to get you to do a particular task, or make a particular change, forgetting that they are making demands on your personal time. As a volunteer, it’s easy to resent this. As a free software author, it’s important to retain command of your project, and not allow others to define it or your tasks. Always remind yourself and others that since it’s open source, they are welcome to create a fork and take it in new directions too. “While I appreciate your feedback, you are not my boss, and this is MY project.” Most users are not like this at all, but all it takes is one to begin building resentment toward all. Ultimately, this robs you of enjoying your project and the community – don’t let them rob you.

While perhaps not a perk per se, another strategy that works is to advertise your limitations. In commercial environments, this is not done. You want people to try and buy your product – you’re not likely to point out what it can’t do, or why they won’t like it. Yet with a free project, I get no kickbacks from having more users. And if users try my software with warped expectations, they will often be upset and negative, in part because they feel their time was wasted trying a tool that doesn’t do the job. While I don’t typically make long lists of limitations, I do try to make clear in web sites, screenshots, and in documentation exactly what this software is about, and what niche it fills. I don’t want to waste my users’ time, and they don’t appreciate having it wasted. It’s much better to clearly define the tool without embellishment. Nor is it necessary to defend or fight for it. This is another habit that developers import from other environments. While you tend to be a fan of your own software, there is simply no reason to fool anyone when its free. The only reason to advertise at all is to see your work put to good use where applicable.

Another strategy and perk I tend to use: use free stuff. I use free web hosts, free issue trackers, free forums, free servers, etc. Many commercial organizations involved with Linux, such as github, offer free services to the developer if your software is free and open source. Rarely do I invest money much in the process of developing and maintaining my software.

In short, get your head straight on what you’re doing and why you’re doing it, and free software development can be a tremendous experience. Having an audience, especially a large audience, can be rewarding in many ways to any artisan, and free software development is no exception in this. Not only is having your work appreciated and used personally rewarding, but the effects of community contributions and ideas to your projects can cause them to grow in directions you didn’t expect. In a sense, users become co-authors of the projects, and this is a very different experience than developing something in a vacuum (which I also know from the projects I don’t take the time to publish). Plus, it’s simply nice to work on something without a need for money involved – it’s liberating to experience ‘the other side’.

Keep expectations low in terms of financial support. Depending on how hard you push for donations and other factors, you may receive some support, but mostly the community doesn’t kick much in. I think to some extent this can use improvement – free software authors need to pay their bills too, and if no one is willing to support them in cold hard cash, opportunities become limited. Remember that “free software” doesn’t mean it’s free to produce, or that you can’t contribute financially, just that what you contribute is voluntary. I believe this is one reason why Linux is being overrun with poorly developed, corporate-driven products which ultimately undermine it – people have come to take the developers for granted. So I do encourage users to support your free developers. Yet I also advise developers to not expect a lot in that area, and to not depend on it for motivation.

Don’t let the lack of financial rewards rob you of a very rewarding experience. If you enjoy writing software (or anything that contributes to the Linux community), do so for your own reasons, and remember the perks of working for yourself, for others.

New Official SpaceFM Forum

The official forum for SpaceFM & udevil has just moved to Parted Magic Forums. Much thanks to Patrick Verner, Parted Magic’s developer and long-time supporter of the SpaceFM project, for his willingness to host it there.

Please see my announcement there for details regarding the old and new forums.

SpaceFM & udevil Updates

SpaceFM 0.8.7 and udevil 0.4.1 are available.

Sandfox users please note the new advisory regarding SpaceFM. Upgrading to SpaceFM 0.8.7 is recommended if you’re using Sandfox. This doesn’t represent any security problem in SpaceFM, yet because SpaceFM is a very capable program that offers access to filesystems via its socket, it’s a good program to lock down or limit in a sandbox. SpaceFM 0.8.7 is a bit smarter in this area, and even if you don’t follow the advice, should prevent use of its socket from within a chroot jail in all but the most extreme cases (requiring a custom program designed specifically to attack it). For high paranoia, follow the recommendations so the sandbox user has absolutely no access to SpaceFM’s socket.

SpaceFM with udevil is now the default file manager in ArchBang, a lightweight Arch Linux system combined with the Openbox window manager.

Mateusz Łukasik’s Lubuntu PPA includes SpaceFM and udevil packages. Mateusz is also the new official Debian packager for SpaceFM and udevil and is working on including official packages in Debian’s repos (not yet available).

NOTE: For those building SpaceFM from source using the instructions in the README, Github recently changed the way they package the source when downloading a tarball. Because they now ignore .gitattributes, the download is over 75 MB and contains all old and new SpaceFM versions and packages. The instructions will still work, but the download is unnecessarily large. I have submitted a bug report to Github and will consider necessary changes based on their response. If you simply want the current release of SpaceFM (master branch), you can download the official tarball here (SF’s mirrors may take awhile to update immediately after a release).

My SpaceFM Plugins Repo

I have created a new github repo for my own SpaceFM plugins in an effort to make them reasonable to share and maintain. Note that this repo only contains plugins that I personally maintain. As always you can find a list of all plugins at the larger public SpaceFM Plugins Wiki.

Currently I have only one plugin there, my IG Burn Tools plugin, which I updated this morning. I’ve burned on a lot of discs with this plugin already and it works great for me. It’s simple so probably not everyone’s cup of tea, but it also demonstrates some more advanced uses of SpaceFM Dialog. I have also added more screenshots.

The github repo method is convenient for a number of reasons. You can watch the repo or subscribe to the feed to receive notifications of changes to any of my (currently one) plugins. You can also review the commits to see exactly what changes were made, and can access older versions of any plugin or file by going back into the git history.

From a maintenance perspective, github (which is free) provides a number of advantages. For example, it includes a wiki and a bug tracker, and it’s integrity checking helps avoid malicious activity. github can also host a homepage for the repo, or you can use the wiki (which can be publicly editable or locked). If you share SpaceFM plugins, you might want to consider this approach.

I setup a single “spacefm-plugins” repo for all my plugins, creating a subdirectory for each. Within each plugin’s subdirectory I added pkg and src directories. The pkg directory contains the current tar.gz plugin file (plus a signature file) for download. The src directory contains the extracted contents of the plugin file (so git can track changes within the plugin, and the contents can be browsed on github).

When I update a plugin, I export it as usual in SpaceFM, saving it directly to the pkg directory, replacing the older version. I then extract it to the src directory (I made a little custom command to do this), replacing the current contents. Then I review the ‘git diff’, commit the changes and push them. People watching the repo receive notification and can review the changes. For example, here are the changes I made this morning to the Burn Tools plugin for version 0.6.

All in all I think this is a very convenient approach, which should allow me to share lots of little plugins with a minimum of hassle as time goes on. But one is a start.

The Dangers of Software Evangelism

From The Sporkbox Blog, a review of the dangers of software evangelism and how it applies to the current situation with systemd adoption, with some devel mailing list quotes.

In May 2011 Lennart Poettering proposed systemd as a dependency for further releases of GNOME. As systemd is available only on Linux, the proposal led to the discussion of possibly dropping support for other platforms in future GNOME releases. While some people responded to the proposal with criticism others suggested the idea of a GNOME Operating System on top of the Linux kernel.

Basically this comes down to: Are Linux users going to allow corporations to take over their OS and change it in unfriendly ways? Because that’s what’s happening.

One of my concerns on this is how poorly these developers maintain these projects. I just came across an easily reproduced GTK3 bug affecting SpaceFM which was reported almost a year ago – with no response yet. That’s one thing you can look forward to when these corporate developers control everything: Microsoft-quality responsiveness and attention to detail.

New Translation Sites For SpaceFM & udevil

It’s now much easier to help translate SpaceFM and udevil into your language. You can visit the Transifex SpaceFM and udevil projects, sign up for a free Transifex account, and use their online editor to translate strings. This way it’s not necessary for one person to do all the work – you can add some translated strings whenever you like. Visit the projects to see how much is remaining to be translated in your language (you may need to reload the page once or twice to see all of them listed for some reason).

There’s also a new Translate page on the wiki for more info. Also see the introduction to translating on Transifex.

Thanks to Delix for helping to set this up!

SpaceFM 0.8.6

SpaceFM 0.8.6 is available. This release includes new Path Bar functionality and other changes as detailed in SpaceFM News.

Feedback is welcome on how the new Path Bar is working for you.

Users of my PPA please note that the following SpaceFM packages are now available: spacefm (GTK2), spacefm-gtk3, and spacefm-hal, plus udevil. At least two Debian packagers are working on getting official Debian packages available – hopefully that will materialize soon.

udevil 0.4.0

udevil 0.4.0 is available. This release adds support for WebDAV via davfs2, so you can mount http:// and https:// URLs to edit WebDAV-enabled websites (these URLs will also now work in SpaceFM’s path bar when used with udevil 0.4.0 or later). For details on using WebDAV and other minor changes in this release, please see udevil News.

Also, SpaceFM with udevil is now the default file manager in the latest release of ArchPup (13.2), the new Debian sid-based distro VSIDO, and will be the new default file manager in the upcoming release of SliTaz.

Upcoming Magazine Article

I’m pleased to announce that an article I wrote will be appearing in the upcoming print issue of Linux User & Developer™ magazine. The article, A Linux Conspiracy Theory, is originally based on my November blog article GNOME (et al): Rotting In Threes, trimming down some of the quoted materials there, and integrating some of the discussions and bug reports which followed. In addition, related issues affecting kernel development and other areas of Linux are analyzed in this context, bringing together a larger picture of what is happening in Linux.

Much thanks to their editor, Russell Barnes, for working with me on this and helping to bring these issues to greater attention.

Linux User & Developer magazine is available worldwide in printed, online and digital forms, including iPad, Android tablets, and PCs. This 6-page feature article will go live in Issue #122 on sale January 17th (in the US, look for it in stores 2-3 weeks later). Look for this cover:

Thanks for picking up a copy and checking it out!