Bugdar 1.2.3 and the Future

Today I released Bugdar 1.2.3, exactly 364 days since the last release of Bugdar. I regret that this release was so long-coming and was far overdue. This release fixes a bunch of bugs that have been accumulating over the course of the past year.

In the future, I will not drag my feet when releasing minor updates like this. The problem is that the current code base for Bugdar (currently the 2.0 Alpha) is quite incompatible with the 1.2.x line. This means, all fixes for bugs affecting 1.2.x need to be redone for 2.0 — which is a lot of duplication of effort. So, rather than continuing to do that, I came up with a better solution.

Bugdar 2.0’s development has been broken up into distinct phases. Unfortunately, due to my own lack of time, progress is slower than I would like. Therefore, I’ve decided that there will be a 1.3 branch to “bridge the gap” between the far-off 2.0 and the current, aging 1.2 branch. Phases 1-3 of the 2.0 development cycle are really underlying architecture changes that just bring the code base up-to-date. After those three phases are complete, Bugdar 2.0 will look and work essentially like version 1.2, but will be more robust and (most importantly) will have a significantly improved language system. It is after Phase 3 that I intend to branch the 2.0 development line into two (the maintenance branch 1.3.x and the current development head 2.0). This would effectively kill the 1.2.x line. And because the two branches would have a more recent ancestor, migrating patches should be easier.

This branching strategy requires little work on my part and will reduce the time I spent migrating patches between branches. Also, it will put in place a language system that will work across 1.3 and 2.0 which is crucial. I have been wanting to create a language pack exchange system so that users can collaborate on and exchange translations of Bugdar, but at present the MO/Gettext system is not good for that. This new language system will be designed to do that. And this branch strategy will get that deployed sooner rather than later.

I wish I could have some sort of timeline for when 1.3 will come out, but I can only really say “as soon as I can.”

Bugdar 2.0 Admin CP

The new Admin Control Panel in Bugdar 2.0.

The navigation system has changed from the tabbed navigation in the 1.1 and 1.2 series. The navigation sections are openable via JavaScript, which will allow navigation of the entire Admin CP from any page, rather than limiting navigation to the current tab section.

Why Go Open Source?

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 [C41 videos]1. 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.

Pipeline Update

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!

Bugdar 2.0 β Phase 1 Complete

I’m pleased to announce today that Bugdar 2.0’s first development phase has been completed. During this phase, all of the Bugdar code was ported to the ISSO3 framework, allowing it take full advantage of property access control, static functions, and the latest ISSO3 conventions.

The point of this phase was to upgrade the ISSO method calls to make refactoring code a simpler process. Had this first phase not upgraded ISSO-based code, the refactoring phase (phase 4) would have been twice as long and twice as much effort because the underlying ISSO code would be out-of-date.

Next in Bugdar’s development is the admin control panel rewrite. Before this can happen, however, a new ISSO3 module must be developed to make creating the admin interface easier. This will include removing the BSPrinter classes (which currently use PHP functions to generate HTML) and replacing it with well-designed CSS style sheets that will be used in templates in the Admin CP.

Separation of the view-controller logic in the Admin CP will make the code more agile and will allow for a more intuitive interface because the HTML will not be generated via on-the-fly code, but rather by designed HTML.