In the latest sprint away from all things Red Hat, Ubuntu is planning to develop its own file manager and is asking for feedback. From Phoronix:
The latest piece of the desktop Linux stack that Ubuntu developers are planning to replace with their own home grown solution is a file manager. For likely inclusion into Ubuntu 14.10 would be a new Ubuntu file manager to replace GNOME’s Nautilus. Users and developers of Ubuntu are growing increasingly unhappy with the direction of Nautilus… Oliver Grawert is currently seeking feedback on the requirements and other sought after features of the new default file manager.
While Ubuntu’s likely file manager doesn’t excite me, the discussion is interesting. And it was good to see SpaceFM and udevil raised in the discussion. Isn’t it time for file managers to support ad hoc commands for mounting and other tasks, instead of binding users to one set of hard-coded system tools?
LWN.net’s Nathan Willis, who previously covered this blog’s viral Arch’s Dirty Little Secret article a few years ago with unusual courage and honesty, has an article back from August which covers several talks at GUADEC 2013, wherein lead GNOME developers talk about the limited uses and ill future of GTK.
In my clear view, the Red Hat corporation has declared itself sole owner of the community-developed GTK project, and is driving it into the ground, making it unusable, probably at Google’s bequest. Their greatest vision for it is making a desktop clock. Any apps larger than that are pushing the usability envelope. GIMP, the original creator of GTK, need not apply.
Meanwhile, Linux developers are flocking to Qt. Yet it should be noted that as soon as Digia aquired Nokia’s Qt, they pledged to become Google’s bitch everlasting. Today, they’re very excited about Chromium. They are controlled by large corporations who make all the decisions and decide the directions. Where do you think that will lead? Why do you think Google didn’t buy Qt themselves? Short of cash? Why use a pawn like Digia?
To me, all of this powerful corporate drive to support ‘cross-platform’ development is merely a game to turn Linux into Windows – to make it so it doesn’t matter what you run, you’re still running a Google product. Google is the new Microsoft. It amazes me how many Linux users think Google is their friend. The Linux community has really become nothing short of stupid, absorbing corporate press releases like populations absorb propaganda. They can’t see even the most obvious attacks, and give their full support to their own demise.
I think it’s safe to say that any spirit of freedom and diversity that once drove Linux is dead. The new people entering the realm of development in Linux are just Windows developers looking for a larger base and more money, or simply corporate whores tearing it apart for short-sighted, malicious goals (which they themselves understand very poorly). They care not for any of the principles that made Linux what it is, or was.
So Linux has been lost because the community has failed to protect it and help it grow. And this isn’t just about toolkits – the infection goes deep into the kernel, udev, the init system, and other areas. In the next few years any remaining GNU Linux users who even know what a principle is, will need to find a new home.
Meanwhile, while you still have a non-Google-implanted brain, you might want to try to figure out why corporations want to (and have always wanted to) completely control the software and abilities of your computer. And you might want to consider differences between Windows and Linux beyond how widgets look. They once represented very different visions of the personal computer.
I recently discovered the mpv video player, which is an actively developed and feature-rich fork of the mplayer/mplayer2 video players. They’ve cleaned up a lot of code and added some nice options (see the differences).
What especially caught my interest is mpv’s ability to automatically save resume points for videos, so the next time you play that video, it plays where you left off, and it also restores the mpv volume and other settings used. Because of this, I have dropped use of my old mplayerstart script, which added resume functions to mplayer.
Like mplayer, mpv does not include a GUI, though it does include a new on-screen control panel. It’s the kind of video player that you control with command line options, usually run in fullscreen, and largely control with key shortcuts. This makes for a great HTPC video player that can be adjusted to operate exactly as you want.
IG SpaceTV plugin for SpaceFM
Toward this end, I have created a new plugin for SpaceFM which aims to turn SpaceFM into a simple media center. The plugin basically makes SpaceFM act as mpv’s GUI for selecting videos, and extends mpv’s resume abilities.
The basic idea is that when you open any video file in SpaceFM, the video immediately plays in fullscreen mode. If you played the video previously and didn’t finish it, it will automatically resume where you left off. mpv also remembers volume and other settings on a per video basis. Plus, you can resume the last video you had been playing (without navigating to it), play prior videos stepping backwards, or browse unfinished videos. You can also set mpv options within SpaceFM, and can play a given video with different options.
Of course there are many other ways to create similar behavior in SpaceFM, but I think mpv provides a great base for this. This plugin is fairly simple, and is intended as a starting point for building and customizing your HTPC (or any media PC). It also shows good examples for how to show simple dialogs, and other features of SpaceFM custom commands. One advantage to using a single script to play all videos is that you can customize this script, allowing it to use special options for some file types, etc.
In addition, the spacetv.sh script can be used independently of SpaceFM to extend mpv’s resume abilities – it only requires mpv. Normally mpv doesn’t remember the names of recently played videos, so it can’t resume the last video you played unless you navigate to it and open it again. With this script, names are remembered so you can resume the last video, or step through prior videos.
I strongly recommend reading the README file to get the most out of this plugin. It works best if set as an opener for all video files (so it’s automatic rather than needing to select it in a menu), and system-wide key shortcuts for Resume Last, etc. are recommended there. To get started visit IG SpaceTV Plugin.
SpaceFM 0.9.3 has been released (see notes). This minor maintenance release stabilizes adjustment of the task manager columns and corrects a few issues.
Happy new year! And happy birthday to SpaceFM, which is now two years old (first pre-alpha release was on Jan 13, 2012). I see this blog had about 100,000 visits this past year, which while a little slower than some years (no doubt due to my fewer posts), it’s still great to see the level of interest, and from around the world too. I’ve made the 2013 and 2012 annual reports public if you’d like to see a bit about your fellow readers and some stats.
Update on SpaceFM Development
SpaceFM development hasn’t been too active the last few months aside from basic maintenance of the 0.9 series, and a few feature adjustments. While this may not be as exciting, it is good news to see that SpaceFM has reached a great level of stability, both in terms of its feature set and in terms of bugs. There are very few active bug reports, and reproducible bugs are usually addressed promptly.
This is a nice place to be in terms of development, because there isn’t much that needs to be done. SpaceFM is generally a complete and capable basic file manager (and DM) that doesn’t change quickly, which I feel is an asset in the current world of Linux. So as a minimum I aim to do the basic maintenance to keep it current, and since SpaceFM is also the file manager I use, I’m easily motivated to do so. SpaceFM also runs in a wide variety of environments and systems, dating back to HAL, etc., as well as the most current GTK3 and udev. As your extensible file manager, you can take it and all your custom tools with you.
Of course no software is ever done, and there are many ways that SpaceFM can develop further. If you find yourself bored with the pace of development, I strongly encourage you to get to know SpaceFM’s Design Mode and Dialog features better. SpaceFM probably does more than you realize, and you can extend it in many ways.
That said, there have been a few things going on here at Ignorant Software. I put quite a bit of work into a new design for SpaceFM’s side panes, particularly a new Bookmarks pane that is more tightly integrated with Design Mode, making SpaceFM’s bookmarks very powerful and context aware. This also involves some redesign of the panel behavior in SpaceFM, making placement more flexible. And it includes some unique new features. The design is mostly complete and looks inviting, yet it’s just a design – a long, long road from seeing reality. I was a bit discouraged by the amount of work it looks to be to implement, especially in light of poor upstream support lately in GTK. It’s a gamble to invest work based on an API whose future is uncertain. So for now this next stage of SpaceFM is pending, mostly waiting for more extensive development time.
SpaceFM contributor OmegaPhil has been working on newly designed archive handling in SpaceFM, which includes a configuration dialog that allows one to set custom handlers to create and extract any kinds of archives in any way, rather than the current hard-coded commands. This work is largely completed and we’re finalizing some of the design choices and behavior before it enters early testing. No precise timing on this but plans are to make a testing branch available for this relatively soon.
In a slightly longer term plan, OmegaPhil’s handler configuration dialog will see double duty in SpaceFM, as I extend it slightly as a dialog to configure handlers for network types as well, and perhaps filesystem types. This will allow separate handlers to be set for each protocol or filesystem being mounted/unmounted, and will enable SpaceFM to make better use of unlimited fuse filesystems and diverging mount solutions ootb. It can currently do this with a custom protocol handler, but the new dialog will make this more user-friendly and capable.
One final thought on completion and development… SpaceFM is ad hoc by design in its handling of devices, networks, and filesystems. This flexibility can be misinterpreted as dysfunction or poor design when it’s not fully configured. Many distros simply package and ship SpaceFM without providing a default session file, for example. This gives you the vanilla configuration. Yet because SpaceFM is designed to work across such a broad array of environments, these defaults are minimal at best, and may not work well with your system without some adjustment. This is especially true of SpaceFM for several reasons. It’s not associated with a DE or other fixed set of system tools (yet can use any). It uses minimal dependencies (basically just HAL or udev, and gtk), and uses only stock GTK icons (it doesn’t have dependency on any icon themes). This gives it a very plain and unassuming look ootb, but rest assured you can give it very different looks and behavior in many regards.
So overall I’m pleased that SpaceFM has reached a mature level of stability and ability. While it’s not my primary project now and gets less attention just because it works well, I think it’s in a very good place for its users and developers. Thanks for your continuing interest!
Also, I made a new plugin Paste Into (aka Paste Into Folder) to paste clipboard files into a single selected folder, or else into the current folder. It is intended to replace or supplement SpaceFM’s built-in Paste command. Some people asked for this in SpaceFM, and this plugin also demonstrates how easy it is to manipulate the clipboard in a script using SpaceFM socket commands, and also how to start a custom copy/move task.
Hope everyone has a great holiday coming up!
IgnorantGuru has invited me to post about potentially useful GNU/Linux projects I’m working on, so here goes!
I am a refugee from GNOME 2 like I assume a fair few of the readers here are, ending up on XFCE4 after some positive experiences early on and the great Linus’ recommendation. One hole I haven’t managed to fill until now is a proper network bandwidth graph in the panel (I used NetMeter for many years under Windows and then Hardware Monitor) – so after finally getting some C and C++ progression, I have managed to port the Hardware Monitor applet to XFCE4! It has reached Works For Me™ status for a week now:
The screenshot is proof of the applet running in XFCE4 along with showing the applet – two Separators delimit the graph on the right, with the red line tracking upload and the green download (the numbers on the far right are from the separate Network Monitor applet).
Hardware Monitor can do a lot more than just a bandwidth graph – see the current maintainer’s site for screenshots.
This release is a bit of an experiment – please report issues on the issue tracker – I’m not after feature requests, although I would love to add some text reporting the graph maximum at some point.
SpaceFM 0.9.0 has been released – please review the changes.
I’m happy to announce that SpaceFM is now included in Debian’s official repos for unstable and testing. This will allow most users to avoid my build-from-source PPA packages, so much fewer dependencies. For stable and older Debian versions, my PPA is still available, as well as other methods.
There’s also a new Ubuntu PPA for SpaceFM and udevil, provided by SpaceFM’s official Debian packager, Mateusz Łukasik. So hopefully we’ll see it working its way into Ubuntu soon too.
Much thanks again to users for their patience and valuable feedback, and to the many translators and other contributors!
It’s been a few months now with no activity on Github from IG, or responses to mail which he usually responds pretty quickly to, even when he has a lot of mail. I have asked for Editor access here in order to cull the spam, but that probably wont get anywhere.
Hopefully he is just taking a well-earned break from pouring effort into SpaceFM, and we can welcome him back soon.
Update: IgnorantGuru returns!
A little GUI toolkit news, courtesy of some links from a reader…
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.
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.
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.