Version control
Hosting of binary and source code downloads over a distributed network of mirrors
Support forums
Issue tracker
Mailing lists
Wiki

The latest development is that the current owners of SourceForge, DHI Group (the former Dice Holdings, which had acquired SourceForge from GeekNet in 2012), is looking to sell off its Slashdot Media assets, which includes SourceForge. It’s too early to really tell what this means for its future, but nevertheless, I’m keeping an eye out for alternatives, and if SourceForge should cease to be an option for one reason or the other, I will be forced to move elsewhere—even considering self-hosting everything I need if I really can’t avoid it.

I’ve never partaken, nor plan to partake, in the controversial opt-in DevShare program that’s been available since 2013 (which would, at the choice of a developer, bundle open source software with closed source ad-ware, and share ad revenues with developers). I’ve observed, with dismay, the project hijackings done by SourceForge of „abandoned“ projects (which weren’t really abandoned, but just weren’t using SourceForge anymore, i.e. development, file hosting etc. continued elsewhere)—thankfully, SourceForge seems to have stopped this practice, but a bad aftertaste remains. I’ve lived with my concerns about the proliferation of sometimes misleading ads on project download pages that was going on for a while, where an ad could consist of only a big green „download“ button, with no clear indication that it actually was an ad and not a download button for the project files (although the situation seems to have gotten better, and I’ve not run into any of those ads for a while now). I understand that Sourceforge needs to pay its bills somehow, but ads have in my opinion been placed and potentially picked strategically in such a way to make it more likely that visitors click them accidentally, or are mislead into clicking them.

Despite my concerns and in some cases disdain for some of the business practices employed by SourceForge, I still feel it provides me with valuable services that aren’t easily replaced (recent service outages notwithstanding)—and by easily, I mean without me having to spend a considerable amount of time setting up alternatives. The matter of fact is that no other free or paid service provider actually seems to provide all the services I currently use (see the list above)—e.g. GitHub is viable for version control, code hosting, wiki and issue tracker, but does not provide hosting of binary downloads over a distributed network of mirrors, forums or mailing lists, which all are important components to me.

That said though, a new owner might actually bring positive change. We will see.

Der Beitrag Quo vadis, SourceForge erschien zuerst bei hoech.net.

Until then, I had used Argyll CMS occasionally from time to time (I remember first discovering it in 2005), and around 2007/2008 started to use it as a tool to explore color and learn more in-depth about ICC color management from a software development perspective (I had prior knowledge as a user of ICC color management as part of my day job at an imaging and prepress house until 2006, before I became self-employed as a web developer).

I also began to grow dissatisfied with the display calibration and profiling software I was using privately, and realized that Argyll CMS did a much better job at generating a hue neutral calibration (an aging CRT that I used back then had a significant green cast in the shadows through midtones in its uncalibrated state that Argyll CMS managed to get completely rid of). I didn’t object to using Argyll CMS from the command line, but started to write a simple graphical user interface in Python (which I already had some development experience with)—with wxPython as the GUI toolkit—that would help me explore the various options without having to remember command line switches and their effects. I had no plans to make my work public at the time, in fact I didn’t even think it would be useful to anyone (it was really, really rudimentary UI-wise).

But in the same year, Argyll CMS hit its version 1.0 milestone, and subsequently I became increasingly aware (by reading forums and mailing lists) of users actually wishing for a graphical interface. I began to wonder if I should build upon what I had and release it publicly under an open source license. So I decided on the not very creative and near unpronounceable working title that would ultimately not change to this day, and began to work on this little project in my free time. I remember an ever-increasing drive and motivation coming along with this endeavor—several other people had announced their development of GUIs for Argyll CMS, and I wanted to be among the first to present something useful. In retrospect, I feel a little silly for worrying that somebody else might beat me to the punch the way I did back then—a few others managed to release their GUIs before mine was ready, but theirs seemed even more rudimentary.

The first version of dispcalGUI, numbered 0.1b, was publicly released on August 18, 2008 and still a bit rough UI-wise, but already fully cross-platform and had a few interesting features, like the automatic detection of measurement instruments. Back then I was definitely a little proud of what I had achieved in a relatively short amount of time. I received a good amount of really positive and encouraging feedback, which I remain thankful for (and keep getting) to this day.
Since then, I continued working on the project whenever I had free time available, adding features, fixing bugs and testing, testing, testing.

Over the years, I increased my knowledge of the inner workings and structure of ICC profiles, and wrote a little parser library to that effect. I learned a lot about systems, packaging, general software development advances, and interesting color and (human) vision related topics. Through following my own internal roadmap, reacting to changes and advances in the supported platforms as well as Argyll CMS itself, and by incorporating user and developer feedback, I kept driving the project forward, even though there were occasions when I had little time to further its development.

In 2010, following users repeatedly asking for a possibility to donate money to the project, I started accepting donations to aid development expenses—beforehand I wasn’t too comfortable with the idea, because I didn’t want to pressure myself into having to work on a project where a main driving factor I felt was that I could work on it whenever I felt like it and had the time, but ultimately that turned out to be a non-issue.

Fast forward. In 2012, I finally hit version 1.0 (although that was never released in binary form, the binary release was actually 1.0.7.6—the last two numbers coincide with my birth year and the release was on my birthday). Since then, development pace has continually picked up, ultimately resulting in version 2.0 being released last year and 3.0 this year with significantly overhauled UI, following an Argyll CMS 1.7 release. This brought another change with it in the sense that I’m now actively asking for donations to compensate for time and resources spent, and because I want to support Argyll CMS itself in a more direct way (all donations received by me are currently split 50/50, after deduction of PayPal fees, with me using one half and donating the other to Argyll CMS each month), the latter being a factor that I previously didn’t give much attention to even though I probably should have (dispcalGUI isn’t really useful without Argyll CMS).

My hope is that I’ll be able to continue working on this project, interacting with users and developers, furthering and refining it as time goes by.

And finally, a few lessons learned during development that may be helpful to people looking to develop a cross-platform application using Python (this is not an exhaustive list by any stretch of the imagination, and I might come back and amend it once more things come to mind):

• Cross-platform and general Unicode support in Python 2.x is not very good. It’s easy to introduce unforeseen issues even if coding carefully (some of the potential pitfalls are mentioned in the Python Unicode HOWTO, but that’s really just the tip of the iceberg). You’ll likely run into unexpected Unicode-related problems depending on platform, when you’d expect such differences to be abstracted away by the module in question. For example this os.walk bug, or the subprocess module—the latter under Windows fails with anything not representable in 7 bit ASCII, under Linux/Mac OS X it works fine as long as the file system encoding can represent the Unicode characters. In such a case, the only solution is to restrict yourself to characters representable in the file system encoding, and hand byte strings over to problematic modules. Or exclusively develop for Python 3.x instead, where Unicode support is much better and consistent.
• Platform differences in GUI behavior can be very annoying and cause unforeseen problems. If you plan to support multiple platforms, think hard about which GUI toolkit you are going to use. If the toolkit you’re considering wraps another toolkit which is native to the respective platform, like wxPython/wxWidgets does, you are very likely to run into these platform related issues. Something like Qt seems a better choice in such a scenario.

Der Beitrag Seven years of open source development—a recap erschien zuerst bei hoech.net.