Roadmap: 1.0, 1.2, and beyond...

I was going to reply to the Cairo graphics library topic in the discussion forums, but my answer started getting too long, and I decided to rather blog about the roadmap of, since in essence that's what was being proposed in that forum topic.

Full steam ahead for version 1.0!

So, our top priority at the moment is version 1.0, and getting it out the door at the end of this month. We have indeed worked long and hard on, to get it to a state where it is a stable, reliable, feature-full application that contains the features that 90% of churches out there are going to need on a Sunday.

So, no more features, just bug fixes, and then out the door with version 1.0.

Version 1.2: Featuritis is the name of the game!

Next up on the list is version 1.2. Internally, there are a number of improvements that can be made to While they won't necessarily seem to make a difference externally, it will make our lives developing and maintaining easier. Once we're done with the code clean up, we'll start entertaining feature requests again.

Of course, we will do our best to incorporate as many of the new feature requests as possible, but some will fall by the wayside. We need to be realistic. Once again, version 1.2 will only run on Windows. We realise that there have been a large number of requests for a cross platform version, but the current version of is tied down to Windows. There's no way we can convert it to a cross platform version.

Cross platform, coming right up in version 2.x!

A while back I started thinking about a cross-platform version of However, I didn't see that much of a demand, and since I was rather involved in getting version 1.0 going, I was glad I didn't have to think about it.

Over the years, however, we've had request after request:

  • "Does it work on Mac OS X?"
  • "I downloaded, but I can't run it in Linux"

So, we're definintely going to develop a cross platform version. There's just one problem: it has to be from scratch. As I mentioned before, currently is not portable at all. It's glued firmly to Windows.

The cross platform version will most probably be written in C++, although I've entertained the idea of using Python. We're not there yet, so I'm still thinking about it (and I'd love to have your input on it, if you've got anything to say on the matter). We'll also use one of the cross platform graphics libraries, like SDL or Cairo, so that becomes truly platform-independent.

Update: At a developer meeting we decided to use Python, as it would be simpler and easier to implement a plugin system.

Of course because we have to rewrite from scratch, 2.0 is going to take a long time to develop. If you are interested in helping out with the cross platform version, please contact me. I'd actually like to get it started now.

So where does that leave us? 1.2 is once again going to be a while away. I doubt we'll have anything beyond beta stage by the end of this year. There's a lot of work that needs to go into it, and since none of the team is devoted to working on it full time, things will no doubt take a little while. I hope to have the first alpha release of 1.2 (i.e. 1.1.0) in about June of this year, although we'll see how far we get.

After a couple of alpha releases we'll have a minor code freeze (no more major features), where we will start working towards a final product. This will be our beta release phase, and after a few betas we'll have a full code freeze (no more features, end of story) and enter into the release candidate phase.

After the release of 1.2, the 1.x branch of will go into maintenance mode. This means that we won't have any more major releases, only bug fix releases. In fact, once 1.2 is out, we will only perform major bug fixes on 1.0, and once 2.0 is out, only major bug fixes will be done to 1.2.

Final words

I hope this clears up things for people. I know that at times some folks have wondered where might be going in future, so this should answer those questions.

Please remember that over and above, has a feature-based release cycle, not a time-base one. We will release each version as and when we see fit, with the features we are happy with, and when we're happy that they are bug-free. That might sound a little dicatatorish, but at the end of the day it's us the developers who have to decide what we can and can't do. We do this in our spare time, and we aren't paid for it.


I'd actually like to help with the development of the cross platform version. Python would make me happy as I thats the language I use in my day job :)

I also have a fair bit of experience with SDL as a few years ago I was working on a game using SDL .net (.net SDL bindings) on the .net/mono platforms and I used to contribute to the SDL .net project ( Although I would imagine Cairo would be a better choice for something like openlp.

I also have my a mac as well my numerous ubuntu linux machines (I generally prefer linux over OS X)... :)



This might be a bit long...


I'd be really happy to help on v2.0.. I've started writing my own proejction software about a month ago - I got annoyed enough at the lack of development in our current system and the flaws it had!


I was targeting cross-platform-ness as well, using an sqlite database in python, potentially using SDL (although at the moment, I'm just using a boggo wxWindows borderless frame for the display! Seems to work fine. One of my bugbears was the lack of automated laying out of text with sensible wor dwrapping and split points, so that's where a lot of my effort has gone at the beginning.

Anyway, I write a lot of python at work, but I've written code in a bunch of other languages, and I don't mind learning another one if you want to go another route! I run linux and windows at home, and I've done opensource stuff before, so I'd be happy to help in whatever way.

Hope that's not all too presumptuous from someone who only discovered the site 10 minutes ago!




Thank you for v1.0's release.  After testing many commercial packages: MediaShout, EasiSlides, EasyWorship, LiveWorship, SongShowPlus, SundayPlus, etc., my conclusion is that when it comes to ease-of-use, OpenLP is king!

Coming from a developer background myself, here's my $0.02:

1. Don't rewrite OpenLP.  Let MacOS and Linux users dual-boot their machine.

2. Focus on fixing bugs, ease-of-use and faster live navigation. KISS.

3. Remember -- most lyric projection software users are _not_ computer people -- they are just regular joes who want to volunteer at church.  Featuritis is why I _hate_ most of the commercial lyric projection software out there.


ginsumaster: "most lyric projection software users are _not_ computer people -- they are just regular joes who want to volunteer at church"

I've kind of been lumbered with dragging our church into the 20th Century (sic!) with lyric projection - I'm probably what you'd call a computer hobbyist. I want an app I can use on Linux, preferably [K]Ubuntu (or another of the biggies like Mandriva, Fedora). If I need to purchase MS Windows to do the projection then I'll find an alternative.

My guess is that church congregations in common with other charities have unlicensed (eg home licenses) versions of MS Windows which they use tortuously. Going FOSS does have benefits.

Why I joined, and posted today, is to question what the developers position is now with OpenSong / ChangingSong (cf and whether contact has been made with Lyricue (developed in Perl, and using SQLite I think).

I've not looked in depth at OpenLP, but have gotten into OpenSong a bit. The interface differences don't seem to be insurmountable. Nor does creation of an XML exchange file format for song lyrics / sets (do such formats exist already in the commercial applications?). Things like display of guitar chords could be moved to a plugin or made as an optional display element.

All I can offer is testing and bug reporting but I'd be happy to add that to a joint project if there is a unity towards this end.

Grace and peace in the name of Jesus Son of God.

Hi pbhj,

We are in contact with ChangingSong (and OpenSong to a certain extent), although not with Lyricue.

We've chatted a little bit about joining forces with ChangingSong, but we have decided to stay different projects (at least for the moment). ChangingSong is still a very young project, and I know that both their project and ours have fairly established interfaces, and I'm not sure that ChangingSong would be willing to change to ours, and we're not going to change to theirs.

So while the idea is great, I think that on a practical level, it won't work that well.

OpenSong was built on a limited, proprietary platform (RealBasic), but the creator has handed the project over to a team of developers who are seriously looking at starting a complete re-write using open-source tools. The project is still in discussion phase at the moment, which is the perfect time to get involved. See

Regardless of whether we all work on exactly the same project or not, the beauty of the GPL licence is that we can use each other's code freely...but the mere existence of a combined project would be a great witness (see the lyrics to the first song of's default playlist). Since the two projects have similar goals, it would be easiest for all of us if we can share the workload on this re-write. After all, this is for Jesus' glory - not our own.

I agree that pooling effort would be the best thing that could happen, although there are differences between OpenSong and that might be difficult to overcome. (Different interfaces. guitar chords and printing are central to OpenSong but not so important to openlp, etc).

The number of different churches around the world shows how difficult it is to get groups Christian's to agree. The likes of KDE vs Gnome shows how difficult it is to get groups of opensource developers to agree. Trying to get two groups of Christian developers to agree would require a miracle :-)

Being a software developer in the past, I am apt to make 3 suggestions:

1. OpenLP 1.+ should fix outstanding bugs -- no new features.

2. OpenLP 2.+ should add some features.

3. No OpenLP rewrite -- period.
Any rewrite for cross-platform interoperability should be delayed indefinitely. I don't see any good cost/benefit in a rewrite.

When you consider:
A. A brand-new Dell laptop costs $420
B. A commerical OpenLP competitor software costs $300
C. Apple and Linux laptops use an x86 architecture.

Question -- Why rewrite?

Any rewrite will be solely for the convenience of running OpenLP natively in MacOSX and Linux. However, since x86 laptops can be easily dual-booted to Windows, I feel that minority of users should either setup their machines to dual-boot or buy a whole new laptop just to run OpenLP. Or they can simply buy a commercial package.

Why ask developers to invest thousands of man-hours for the convenience of the small minority of non-Windows users? It makes NO SENSE.

It's not only for the so called "small minority" of non-Windows users. It's also for would-be developers. 1.* is written in Delphi. This isn't free, so currently development is restricted to the few people who can afford it or have access to it via work/college etc.

This puts a lot of pressure on this very small number of volunteer developers who already have very busy lives. There are not enough hours in the day for them to add the features the growing user base wants/needs, let alone fix all the bugs.


1.0.* will be bug fixes
1.2.* will be new features to the current version.
2.* will be in Python (agreed by vote at the IRC developers meeting last night.)

As I understand it, Raoul and the existing team will continue to work on 1.* so development will continue at the same pace as now. A new set of developers (who are quite willing to invest their time however much sense you don't think it makes) will start work on 2.0

In addition. Your church may be able to fork out for $420 laptop or $300 software package on a whim. Our church is looking at multi-thousand pound budget deficit this year due to increased costs outside our control. OK we already have a Windows machine so it isn't an issue for us, but if it was, we'd be looking at cutting costs whereever we could.

I see the problem as Vista and Friends. The Dell $400 laptop will have to run Ubuntu, because it flat out won't run Vista. Especially with video. I've got a Dell 1720 (about $1800) Dual booting Vista and Ubuntu. Vista is a dog.

Our current projection system uses MediaShout on XP. There is no way it can survive an upgrade to Vista.

You can be assured the upgrade path for MediaShout will take us through Vista.

A 2.0 version of running in Mac and Linux could gain some market share, especially because of Mediashouts failure to implement on Mac.




I agree with the comments.  The work to build OpenLp1.0 has been a long road as there have only been a handful of developers.  Moving to python will allow more people to get involved and add new features as well as fix bugs more quickly.

If the software were modularised correctly the chance of regressions should reduce.

The project will need strong leadership to control the checkins but that is valid.

Out church is very good at using old PC's for different uses.  We are still running windows ME on one machine cos it works!!!