People sometimes ask me why I don’t charge for the software I write. I explain to them that, to me, it’s not about the money. But that’s only part of the story. After thinking about it there are a few reasons why I release everything as open source.
1. You’re Giving Back to the Community
This is what the entire FLOSS community and its mentality is about. You have this great software and you want to give back to the greater community by making it open source. Doing so means that all developers can see how you’ve chosen to implement certain things, they can borrow code, and they can help improve software by submitting patches. For me, I learn a lot of programming languages and techniques by dissecting open source software, and I feel it’s only fair for me to give back to the community as much as it has given me.
2. You Don’t Worry About Business
I’ve been reading some articles about indie development and I watched all of the C4[1] videos. From doing so, I’ve realized that starting an independent software shop is a lot of work. You have to get a credit card processor, you have to have a licensing infrastructure, you have to worry about piracy, and (arguably the most difficult) you have to find the right price for your software. We’re software developers, not business people. This is not my idea of a good time and I’d much rather spend time developing rather than doing the aforementioned tasks. Going open source frees you from all of that.
3. People Can’t Have Expectations
That is sort of a half truth. People will always have expectations about software, regardless of whether or not they pay for it. But when you develop open source software, you’re essentially a volunteer. People get what they pay for. I try to do my best in creating software and supporting it, but because it’s open source, there’s no expectation that I have to. As a full-time college student, I don’t have a lot of free time — I develop when I can. If I had paying customers, there’d be an expectation for future versions on a reliable time scale, but I’m not under that pressure. Additionally, I do not have to support this software with immediate email responses, blog follow-up comments, or forum posts. I do so because I like doing so. If this were a business, people would have high expectations for support, but because I do open source work, if I deliver good support, it’s only a bonus. If I don’t, they really can’t complain because they don’t pay for anything.
It’s been a while since I discussed pipelines, so I’m going to talk in this post about the state of various projects, as well as some talk on new projects!
COMPLETED PROJECTS:
MacGDBp
Released this summer, MacGDBp has been a tremendous success. This week version 1.1.2 was released, which address two bugs, one of which was a crasher. I’ve got big plans for version 1.2 and 1.3, but these will have to wait for other projects to be completed.
CMS
In my last pipeline update, I mentioned the CMS I was building for my university’s TV station. This project launched only two weeks ago, so the past month and a half I’ve been working feverishly to get this done. It’s now complete and so this will no longer be affecting development.
CURRENT PROJECTS:
Bugdar 2
The first milestone in Bugdar 2′s development phases was completed a few weeks ago. Since then, not much has happened because all of my effort went to deploying the aforementioned CMS. However, work will be resuming on phase 2 and development will be continuing. This week I went through the Blue Static bug tracker and triaged a bunch of bugs that had been left unresolved.
NewzGrab
I’ve started working on this project in the past few days. As stated in the previous pipeline posts, this is a Usenet downloader for NZB files. However, I’m writing this as a cross-platform application. Most of the code is being written using C++ and Boost, which allows it to be platform-portable. I intend to then create native interfaces for various platforms (initially, only the Mac one will be created).
MyWishlist
This project is mostly complete. A few interfaces need to be updated and created, but on the whole this is largely done. I haven’t actively worked on this in a few months, and I consider it to be one of my lower priorities.
NEW PROJECTS:
iD3
I realized the other day that the Mac lacks a good, free ID3 tag editor. I quickly found id3lib and wrote a simple Mac interface for it. Version 1.0 will be released in a few days, but will be very minimal. I intend to add more features (and more tags to edit) in the future, but the necessary fields will all be present in v1.0.
“Commander”
This is the project I’m most excited about. It’ll be a unique take on launchers (e.g. QuickSilver, Butler, LaunchBar) that is for pro-users only. I won’t be going into the details until I have something to show, but this will be one awesome app!
I’m pleased to announce the immediate release of Scrabbalize 2.0. This version adds wildcard support. Merely add a ‘?’ to your tile set and it will match any letter:
And as you can see, the new version has a completely redesigned interface that looks fantastic in 10.5. Finally, as an extra treat, I have made it 10.4-friendly. So you can now run Scrabbalize on Tiger!
Enjoy.
Inmy last pipeline update, I said that MacGDBp would be out by May. Unfortunately, I’ve run into two bugs that I’m not quite sure how to work around. One of them involves NSXMLDocument raising assert() messages for what appears to be valid XML. Weird, right? So instead, I’m going to write an article about MacGDBp in hopes of whetting your appetite for it until it’s done.
History
The idea for MacGDBp has been in my head for a long time. PHP debuggers are far superior to var_dump() and print_f() debugging statements. Unfortunately, only the Zend IDE was available — but it cost money and was ugly (i.e., not Mac-esque). Next came Eclipse with the web tool kit. I had a heck of a time getting the debugger to work and ultimately gave up. Additionally, it too was ugly. So I put up with my combination of BBEdit (and later TextMate) and var_dump()/print_f().
Fast forward a few years to the introduction of the Xdebug extension. This extension is absolutely fantastic, if only for the stack traces in errors and uncaught exceptions. But it also has a remote debugging function. For about a month, I used the packaged command-line demonstration tool and read XML to glean debugging information. Then at the end of July/beginning of August 2007, I made the decision to write a native Mac application for the Xdebug remote debugger.
Evolution of Design
It’s rare for me to design an application without first sketching out the interface on paper. But because this was such a straight forward project, I decided to wing it. The second commit in the git repository was “Laying out an unhooked basic interface for the system.” This was the first revision.
Yes, ugly. But it improved after some tinkering:
Then I realized that I was trying to re-invent something that had already been well-designed. So with the next iteration, I mocked up Xcode’s debugging window.
After designing a couple of toolbar icons, we get to the final design. This is how the application will look when launched and unconnected to Xdebug:
And there you have the final design. In the next couple of days I’ll talk about how I designed the icon in an effort to stall while I squash the last few bugs.
A Note about System Requirements
MacGDBp will require 10.5. And this is not because I don’t want 10.4 support, but MacGDBp relies on a bug that was fixed in 10.5. In Mac OS X, there is a class called NSTreeController that I use for the variable list. But under 10.4, parts of this class were not properly exposed and were very buggy. I found a work-around, but it relied on using private, undocumented API calls. In 10.5, Apple fixed the bug and exposed the necessary parts.
Two months ago I gave an update on my entire timeline of projects. This will just be a quick rundown of the projects and their status.
mkrcpt: Shelved, probably indefinitely. It turned out to just not be that useful. I’ll push the git repository in the near future, however. But this will not be officially released or supported.
MacGDBp: The icon is done as is the line numbering in the source view. I’m now just fixing some bugs and finishing off the breakpoint manager. This should be out the door by the end of May! As this comes near completion, I’ll hopefully start drumming up interest in it. Stay tuned for more information.
CMS: This is almost done as well. There are a few more modules I need to write, but the architecture that I’ve already written will make that quite simple.
All the other projects are at the state detailed in the last pipeline update. But this is progress, at least!