New project: libwm

My new project got approved. From now on I’ll be working on Libwm, a cross platform Windowing and Context management library for OpenGL. I am delighted that I got this chance to work on the library. Next up, I’ll start to work to get the first release of Libwm out.

I already started with a nice coding spree, I did a major rewrite of the wgl and glx parts of the library and also got some things done that had been left hanging since the spring when I last had the time to work on Libwm. I did major improvements in the framebuffer pixel format setup and keyboard event handling code. I also did some documentation and clean up.

Here’s my new project plan and from next week on I’ll get hacking.

Project plan – Libwm

Introduction

Libwm is a cross-platform C++ library to help with windowing, event handling and context creation in OpenGL applications. It’s target audience is OpenGL application and game developers. Libwm provides an abstraction to platform specific windowing systems like the X Window System and OpenGL context set-up API’s like GLX on X Windows or wgl on Win32. The Libwm project was started in February 2009 and, as of July 2009, weighs in at about 7000 lines of code. With an established solid code base, the project is heading for it’s first release.

Task – Finalize and release Libwm

To survive, an open source project must attract the attention of users and developers. To do this, a project must have a easily accessible release distributions, complete with libraries, developer files, examples and documentation. “Release early, release often” is the motto and the key to success.

The Libwm code base is already quite stable, but other aspects like documentation, examples and distribution files need a lot of work. A software distribution, especially a library, must have these things sorted out to be appealing to developers and users alike. Some project management work is also required, the project web site must be set up and maintained and an issue tracker should be employed.

The goal of the Kesäkoodi project is to relase the first version of Libwm, complete with good documentation,
source and binary distribution tarballs, Windows binaries, Debian packages and Mac OS X framework bundles and nice examples.

Schedule

I’ve got seven week of time remaining and my goal is to get in shape for release in four weeks. It is an ambitious schedule, but luckily there’s a couple weeks of time left if I don’t make it. If and when I get the release done, Libwm is far from finished. There’s plenty of new features to be added and lots of different OpenGL extensions, versions and platforms to support. The work will be about 50% of coding and 50% of project management and janitorial tasks.

Week 1

Issue tracker

In order to document and keep track of the project’s progress, an issue tracker should be set up. Google code offers a nice issue tracker that can be used. All planned tasks and features should be added to the issue tracker. With only a few weeks of coding time before the planned release date, a small set of tasks is chosen to be implemented in the first release, others will be saved for later versions.

Doxygen

Doxygen will be used to generate a nice API documentation. Doxygen should be set up and integrated to the build system to get documentation easily generated, installed and distributed. Doxygen annotation comments in the source code should be improved.

Code

The first few weeks will mostly consist of coding the missing parts of Libwm. This includes better handling of mouse events, especially on the Windows platform, improved event listening routines and better error handling. As soon as the release feature set is determined, I should get coding right away.

Week 2

CMake/CPack

Libwm is built using CMake, a cross platform build configurator/generator. CMake is pretty nice, it handles finding dependancies and configuring the build system as well as building documentation, installing and generating distribution packages with CPack. The CMake build system is working pretty fluently, but the build system still needs some fine tuning. CMake and CPack should be configured to generate distribution packages for runtime and development libraries and the documentation separately, in various formats from tarballs to Debian packages and Mac OS X frameworks. This should go pretty fluently with CMake and CPack, after all, that’s what they are designed for.

Example apps

A good library needs a good suite of example applications. The example applications also serve as a testing platform for the library. A few example applications should be written using various features of the Libwm library in different ways.

Code

Keep on coding the features that should be included in the release, there should be plenty of time and plenty of work to do.

Week 3

Code

Most of the features that should end up in the first release should be finished by the end of this week. It’s time to code hard to get things in shape for the pre-release code freeze. If all goes well, all the coding tasks for the release should be done by the end of the week.

Documentation

As the code base becomes more stable, it’s time to document it. The API docs should be done by now, but a good documentation is more than that. Add a high level description about the library, a tutorial and a lot of examples in the documentation.

Bug fixes

As the release gets closer, the code should be cleaned of nasty bugs. It’s time to fix all known bugs so far and hunt for new ones by hacking with the example and test applications. Also try to work on handling incorrect use of the library gracefully.

Week 4

Code review

The final week before the release should concentrate on code review, cleanup and fixing. It’s time to read through the entire source code, find and correct bugs and comment tricky parts of the source code. Google Code has a nice code review feature where users can review, comment and grade the code and add remarks to individual lines of code as well as on a per-file basis. I’ll try to find a friend who would have the time to browse through the code and add review comments.

Bug fixes

The code review may expose new bugs, find and fix as many bugs as possible.

Unification of implementations

The Libwm library has separate implementations for Windows and Xlib. Ideally they should behave exactly the same way, but in practice there are minute differences. Test side-by-side with as many platforms as possible,
find the differences in the behavior and try to unify them. If there are features that are not portable, handle them in a sane manner or remove the features from Libwm altogether.

Release

It’s time to roll out the release. Create distribution packages for all platforms and verify that they install and work correctly. Digitally sign the packages and put them available for download on the project web site.

Week 5

Buffer time

It never hurts to have an extra few weeks in your project schedule. If the original release schedule isn’t met, try to finish the release as soon as possible.

Web site

The project web site also needs some work. The project page should be made informative and appealing, complete with screenshots and code examples. Google Code has a nice wiki that can be used for documentation.

Promotion and PR

When the release is out, it’s time to promote the project to other developers. Post announcements on relevant forums and mailing lists and IRC channels to attract the attention of potential users and contributors.

More features

When the first release is done, there’s still plenty of work to do and features to add. If there’s time left, it’s time to work on new features. Potential features include full screen support, OpenGL 3.x context creation using the ARB_create_context extensions, multisample antialiasing, shared exponent visuals, floating point pixel formats, etc.

Week 6

Buffer time

If the release isn’t out by now, it’s time to hurry up and get it done. Hopefully the release is already done and we have some extra time on our hands to work on new features.

More features

Keep on working on new features to the library.

Week 7

Final report

I will spare all of the last week to make my final Kesäkoodi report. I’m lousy at getting things like this done. Hopefully there will be some time left for coding too.

Risk analysis

Not finishing

The biggest threat of open source development is not finishing a project. To get the first release of Libwm out there, I should work consistently towards that goal. To meet my schedule, I will have to carefully choose the features I want to implement and what to leave out and stick with my plan. I feel that the Libwm project is on a solid base and the release can be done in schedule.

Killer bug

Before the release, Libwm is going to need a lot more testing. Surprising bugs may come up and fixing them might be hard. If a particularly difficult problem arises, the schedule may be delayed. If a real rogue bug strikes, it may be better to stick to the original release plan and document the bug to be fixed later. Overall, the Libwm code base is pretty simple and small and even major parts of the library can be quickly rewritten. Should a difficult bug come up, fixing it should be doable within the time frame.