PaperCut Blog

Inside PaperCutLife @ PaperCut

Happy Birthday PaperCut!

PaperCut was originally started back in 1999 making it now 8 years old. The code written back in 1999 stood the test of time well and in fact remanent of the original code remain today in the PaperCut Quota. In 2005 we embarked on a project to re-architect PaperCut – the result being PaperCut NG. Today PaperCut NG is 2 years old! It’s amazing how time flies.

Last year I posted an article graphing our progress with PaperCut NG. As you’ll see from the updated graph, our progress has not slowed and we’re now up to 450,000 lines of code!

PaperCut Trunk Lines of Code (LOC)

Some History

Here is a screen-shot of the original PaperCut website, circa 1998/1999 (very ugly… but we’ll call it “retro” to be nice!)

PaperCut Website (circa 1999)

Here is a screen-shot of one of the first versions of PaperCut. Notice the cool “Windows 95” style icons!
An early screen-shot of PaperCut


  • Nick

    Surely lines of code is not a measure of good software. Frequently–indeed quite possibly inevitably for projects which plan to stay maintainable and competetive–smaller, simpler, pluggable code is the best policy.

    Pidgin is a good example of a software project which recognise this; they’re currently playing with the idea of bounties for contributions which reduce code size without reducing functionality. See for more.

    37Signals have a nice section on the issue of over-coding in their book, which can be found at

  • Chris

    Hi Nick,

    I totally agree. The “lines of code” graph was put up not so much to highlight quality or features, but more as a crude measure of “rate of development”. It refers to my post last year highlighting that PaperCut is always under active development. A graph is a visual measure – just something to make the post pretty – but I suppose ultimately the best measure is the release history and list of new features!

    I also agree with your statement on maintainability. For example, a few months ago we refacted our popup authentication code – arguably one of the most complex and security focused areas of our application. The change took almost a man week, and resulted in next to no functional improvements. The code line count in this area however dropped by half and more importantly it was easier to understand. The driver for the change was to fix a small bug, but we took the opportunity to refactor to minimize the possibility of accidentally adding new bugs in the future – that is an investment.