1. 56
  1.  

  2. 7

    Very interesting read.

    I’m parted when it comes to some lessons: the author aimed for very small and attributes part of the success to that but I think it would have been similarly successful by being merely small. At that time the competition was basically Adobe Acrobat Reader which was already huge and slow. FoxIt Reader came a bit later than SumatraPDF and was bigger but still much smaller than Acrobat Reader but then it grew larger and larger. IIRC the speeds were roughly as follows: SumatraPDF might take <~100ms to launch, FoxIt would take >~1s, and Acrobat Reader ~10s. That left a huge gap for a small-ish application.

    I think the need to avoid non-small dependencies is far less important than stated. The author is still free to do so obviously but I think the reasonning in the blog post is sometimes wrong.

    1. 5

      Most readers are still single format and I do believe being multi-format helped SumatraPDF become popular.

      Can’t speak for most people but I’ve been using it as a PDF (and only PDF) reader on Windows for far longer than the browsers have builtin PDF support.

      So if the author is reading this, thank you for freeing me from Adobe Acrobat Reader, many years ago. And this blog post was awesome, really nice to read.

      1. 4

        I’m somewhat curious that the author never mentioned licensing. He switched from Poppler (GPLv2-only) to MuPDF (AGPL) as the rendering engine. It looks as if SumatraPDF is GPLv3, but the commit that made the license GPLv3 says that it was done to match MuPDF’s license (which has apparently changed since he did it) and it was a relicense from GPLv2 (so persumably had approval from all copyright holders: he mentions that most of the code was developed by two people, so that might have been easy, as long as he kept track of all external contributions).

        This whole process sounds like it must have been fun to work through and I’d love to hear the lessons he learned.

        1. 3

          If you’re not embarrassed by your app then you’ve waited too long to release it

          I like this too, but it made me go check how many private repos I had.

          1. 2

            Very enjoyable read !

            Regarding code quality, I 100% agree that adding an automated crash reporting system is a must have ! At $work we learned it the hard way: having to understand why your mobile app is crashing at startup while not losing its sensitive data, and you have to be very quick about it because the client is in a hurry… a pleasure.

            On the server, process those files and generate web pages for easy viewing of the crashes. It looks like the cherry on top, I love it.

            1. 2

              As its open source I really wish author would ‘port’ it to Linux/FreeBSD.

              SumatraPDF is so good that I use it daily on FreeBSD using WINE instead of some ‘native’ PDF viewer - I use mupdf for ‘fast’ displaying the PDF file but when I want to read a lot then sumatraPDF is the way.

              I do not like the newer versions tho - stayed at SumatraPDF 2.5.2 - works best for me.

              1. 2

                At the time I didn’t know that PDF is popular

                This surprises me. How could any developer in 2006 not have known that PDF was popular? Was it much less popular in some parts of the world?

                1. 1

                  It’s surprisingly hard to find an easy to use memory leak detection tool

                  For Linux (and I ported it to FreeBSD) KDE’s heaptrack is excellent.

                  1. 3

                    In that case it wouldn’t help because SumatraPDF is explicitly a Win32-only app, so unless you want to do leak detection under Wine this is a no-go.

                    1. 1

                      What’s wrong with valgrind, asan, bdw…?

                      1. 1

                        Nothing. Where did I say there’s something wrong with other tools? :) Heaptrack is great because of its UI.