Kiwix/Plan 2018-2019/Final
Welcome to this project's final report for 2018-19! This report shares the outcomes, impact and learnings from the grantee's project. For the initial plan, see Kiwix/Plan 2018-2019
Part 1: The Project[edit]
Summary[edit]
Kiwix has met or exceeded most of its objective for the fiscal year. Our mobile user base keeps on growing and generally speaking our code is more robust. A series of regressions with MediaWiki Offliner have prevented us from updating the larger wikis, but we've successfully released the topical subsets and implemented the creation of localized landing pages that allow us to reach users whereever they are, in their own language, with content they can relate to and enjoy. We've also been late with our android dev recruitment, but once this has been solved the pace of improvements has been brisk.
Project Goals[edit]
The broad and ultimate goal was to facilitate the distribution of Wikimedia contents to people without reliable internet access, either directly or through third party organizations. To do so, we needed to:
- continue to upgrade and maintain Kiwix code, so that it is easier to manage for technical contributors;
- improve accessibility and user experience.
The expected outcome being that (i) people without internet access can nevertheless access Wikimedia content; and (ii) a cleaner code makes it easier for new contributors to contribute features and support maintenance.
Project Impact[edit]
Targets[edit]
| Target 1 | Measurement method | Baseline 30 June 2018 | Status
30 June 2019 |
Comments |
|---|---|---|---|---|
| 15% increase in number of end users of Kiwix. | Baseline/endline number of downloads and retained 30-day installers as measured by Google Play console.
Baseline/endline number of downloads as measured by Kiwix servers. |
|
|
Download.kiwix.org mostly reflects desktop usage. |
| Target 2 | Measurement method | Baseline | ||
| Android retention at D+30 exceeds 40% | Google Play Store stats | 40.2% at D+30 | 42.7% at D+30 | |
| Target 3 | Measurement method | Baseline | ||
| Reduce android crash scenarios for all versions by 50% | Baseline/endline from the Google play console | Kiwix 2.2
ANR: 0.34% |
Kiwix 2.5.1
ANR: 0.2% Crash: 1.83% |
Meh. But then the Android dev only started in May 2019. |
| Target 4 | Measurement method | Baseline | ||
| Create zim Farm
90% of zims automatically updated on a monthly basis; |
Publication date at D-30 and D-60. | 0% (all zims updated manually) | 95% of Wikimedia zims updated monthly
98% of Wikimedia zims updated bimonthly |
A few of the larger zim wikis (>500k articles) still not integrated to the zim Farm. |
| Target 5 | Measurement method | Baseline | ||
| 30% increase in testing code coverage | Measure of code coverage (tested before the program starts and quarterly during the program) | Est. 40-50% (Kiwix android) | Zimfarm: 69.7%
Libzim: 69.3% MWoffliner: 61.8% Kiwix-android: 34.3% |
We only recently moved to a proper code coverage measurement program (codecov.io)
Kiwix-tools, Kiwix-lib, Kiwix-build, Kiwix-desktop, zimwriterfs not migrated yet. |
Outputs[edit]
| Outcome #1 : improve access | Comments |
|---|---|
| Release zim files built for mobile devices based off research conducted by Wikimedia Foundation Android team in 2017. Files should be 100mb or less in size, multilingual (10 languages), and topic-specific (10 topics). |  Done
The following subsets are now available:
|
| “Fresh” content available for download with the release of a fully automated zimfarm. New versions of existing zim files would be available for download on a scheduled basis (monthly for 90% of files, bimonthly for largest). Automate zim landing pages generation. |  Almost done
|
| Publish strategy for Customer audience (e.g. NGOs) | Done See here |
| Outcome #2 Improve code | |
Android redesign:
|
Almost done
|
| Professionalize key aspect of development. Our software portfolio (zimwriterfs / zimtools / libzim / kiwix-lib / kiwix-tools (C++), MediaWiki Offliner (Javascript)) is maintained by contracted employees so as to have regular and reliable release dates. | Done
|
| Organize two hackathons to solve platform-specific issues | Done (Zurich & Debrecen, participated in Prague Mediawiki hackathon) |
Story[edit]
Young Billy comes to class and the teacher asks him: "Do you know how many times you've been late this year?" "Well, Miss, I reckon it's never been more than once a day." The good news, as far as we are concerned, is that Billy's still acing his exams (or as the table above shows, mostly aces them).
This was our first year with a full partnership grant that was not dedicated to a single project (like Wikimed or desktop UX) and again this was an eventful one.The overall good news is that Kiwix keeps on growing. The bad news, is that we are not growing fast enough. The fine print of it all is that, again, as a young structure, we first had to figure out how to do things before we could do them: while it never really impacted our ability to deliver what we had promised, it sure impacted (negatively) when we could deliver these.
Hard lessons[edit]
Case in point: android. We had planned for a swift recruitment process and start by January/February 2019. We posted ads, made noise on social media.... and waited. To no avail. And here is the learning: it's all about location, and we hadn't posted at the right places. Free job boards only brought us Belarusian and Indian code factories rather than the individual developers we were looking for. So we had to ask around (namely, the Foundation folks) where they got their people from, and from there had to pay quite a bit of money to have our ad posted at the right places. Bottom line: extra costs (the multiple ads added nearly USD 1,000 to our budget), and delay: the android dev we recruited is awesome, but he also started in May (i.e. more than a full quarter later than expected).
We also had a couple of regressions - times where code was technically worse than when we started touching it: this is what we endured with mediawiki offliner, the tool we use to convert Wikimedia dumps to zim files. We have made more than 18 releases (from 1.5 to 1.9.3), and while this partly reflect a better effort at continuous integration and use of milestones, the backstory to it is that for a while it would crash when faced with too big a zim file (or did work, but only to crash when we tried to implement it onto the zim farm). Most wikis bigger than 500k articles could not be updated almost until the very end of Q4, and even now that it's (hopefully) fixed, the fact that we have to juggle resources means that it's not fully implemented: for people using Kiwix to access Wikipedia in French, English or German, then this means having to live with copies that are about 8 months old (for English, this means only 5,733,761 articles available instead of the current 5,904,132 - shame on us). But necessity is mother of invention: while we tried to fix this, two separate strokes of genius luck genius came about.
Sweet findings[edit]
The first one is very technical and basically cut our generation time (i.e., the time it takes to compress a dump into a single zim file) by nearly 80%: this was somewhat unexpected as it was the result in improvements from the kiwix libraries rather MWoffliner itself (but then the latter heavily relies on the former). The other major improvement is more visual and related to the thematic subsets we'd endeavoured to develop: starting from the assumption that downloading and storing 78 Gb isn't exactly for the meek, and based on Wikimed's proven success of giving people what they wanted rather than all of what we had (including what they wanted), we wanted to dramatically reduce the size of our individual offering (even if that meant to just as dramatically increase the breadth of it). This also meant that had to work out a way for MWoffliner to figure out a way to create a thematic landing page. The very old way to do this would have been to simply copy the Wikiproject's landing page, much like we currently copy Wikipedia's or the Wiktionary's current landing pages, with their image du jour and other niceties which turn out rather stale in offline settings where people get to stare at the same du jour for months at end. Not good. The less old way is somewhat better in that we spend some time to create a custom landing page to remove all the unnecessary. The problem remains however that (i) we need to spend some time figuring out a list of links for that landing page, and time is money; and (ii) that only works for languages we somewhat master: the tasks is simply too daunting to humanely manage in languages (and scripts!) we have no idea about (I'm looking at you, हिन्दी विकिपीडिया).
Enlightenment here came from an unexpected quarter, though to be honest it has been enlightening the rest of the movement for some time now: Wikidata. In this case, we decided to first look at traffic statistics for each subset (e.g., which articles are most visited from the History or Football groups). Then we took that list and asked Wikidata if it had any image associated with it (Property P18). We then took the 100 first such items, and then assembled them as tiles, meaning that our landing pages now is both visually more compelling (images!) and relevant. And as a bonus, thanks to Wikidata we even have the articles' names in their original language and script.
- And voila.
-
Chinese -
English -
Hindi -
Turkish
Heavy thinking[edit]
The third important deliverable this year was our definition of how we would handle partnerships going forward. Besides individual users who download and use Kiwix on their own, Kiwix also works with a rather wide range of partners - from the conventional NGO making large deployments (e.g. the Fondation Orange in West Africa) to the more exotic Human Rights Foundation in North Korea, and pretty much everything in between, including other Wikimedia-supported projects like Internet in a box.
We first had to decide what our ambition was; then where we would deliver, how we would deliver it and what it would take to do it, and finally how we'd measure success. Based on this, we then had to decide which of our partners we would focus on. The full deck is linked on this page but the short story is that for us to become (or remain) the leading offline solution for knowledge access, we had to focus on ease of use and simplicity so as to keep our product as affordable as possible and easy to integrate in programs or other technical solutions. We are looking at reaching 100 million users, and this means focusing on partners who can scale, either directly using Kiwix (e.g. a teacher's organisation as opposite to, say, an enterprising but lonely school teacher) or through re-use (e.g. IIAB). While the former certainly entails a measure of brand building, the latter will most certainly mean distributing Kiwix as a white brand : we are okay with that, just as nail manufacturers are okay with contractors building as many houses as possible with their product.
Metrics[edit]
We estimate our user base to be upwards of three millions, worldwide.
- download.kiwix.org (direct access, desktop downloads): 906,000 users (vs. 989,000 in FY 2017-2018)
- android:
| Active installs on June 30th | 2018 | 2019 | Change % |
|---|---|---|---|
| Kiwix app | 59,813 | 151,511 | +153.3% |
| Wikimeds | 100,097 | 114,710 | +14.6% |
| Other apps
(PhET. Wikivoyage, WikiSpecies) |
28,366 | 42,697 | +50.52% |
| Total | 188,276 | 308,918 | +64.1% |
Note: user retention for the medical apps is around 70% (+/-5%). People seem happy with the apps, but there certainly is a problem with search and discovery. We also clearly underperform conversions from the playstore's landing page.
- From iTunes (iOS, macOS): 1,072 (vs. 670)
- Firefox, Chrome, Windows (Kiwix-JS): ca. 4,000 (vs. <1000)
- Other distributors, partners, integrators (e.g. IIAB, Libraries without Borders, Orange, RACHEL, etc.): ca. 2,000,000 (=)
Project resources[edit]
Please provide links to all public, online documents and other artifacts that you created during the course of this project. Even if you have linked to them elsewhere in this report, this section serves as a centralized archive for everything you created during your project. Examples include: meeting notes, participant lists, photos or graphics uploaded to Wikimedia Commons, template messages sent to participants, wiki pages, social media (Facebook groups, Twitter accounts), datasets, surveys, questionnaires, code repositories... If possible, include a brief summary with each link.
As always, all of our content is open-source and available
On Github
On Commons
Next steps and opportunities[edit]
The full plan for next year (2019-20) is online and available here. While we will maintain the level of structural stability we have recently reached, our focus will now increase to actually growing users - both directly, by offering a broader range (incl. non-Wikimedia) content, and indirectly, through partners. We will also increase our work on the Kiwix hotspot (previously supported via a Fondation Orange grant) and which has shown promising appeal among Raspberry users.
Part 2: The Grant[edit]
Finances[edit]
Actual spending[edit]
| July 1st, 2019 - June 30th, 2019 | Budget | Actuals |
|---|---|---|
| WMF Grant revenue | Fr. 236'000.00 | Fr. 236'000.00 |
| Personel spending | ||
| - Salaries & empl. taxes | Fr. 62'100.00 | Fr. 68'732.34 |
| - Contractors | Fr. 110'000.00 | Fr. 151'071.87 |
| Total Personel | Fr. 172'100.00 | Fr. 219'804.21 |
| Non-personel expenses | ||
| - Rent | Fr. 6'698.94 | Fr. 6'257.37 |
| - T&E (incl.hackathon) | Fr. 24'000.00 | Fr. 23'386.00 |
| - Hardware | Fr. 5'000.00 | Fr. 6'824.22 |
| - Servers, licenses | Fr. 24'000.00 | Fr. 9'202.54 |
| - Varia | Fr. 2'000.00 | Fr. 1'348.15 |
| - Admin and bank fees | Fr. 1'600.00 | Fr. 780.80 |
| Total non-personel expenses | Fr. 63'298.94 | Fr. 47'799.08 |
| Total spending | Fr. 235'398.94 | Fr. 267'603.29 |
All amounts in CHF (CHF 1 = USD 1 (+/- 0.02))
Remaining funds[edit]
No remaining funds.
Grantee reflection[edit]
Once again we believe that the Foundation has been getting good value for money. We've grown tremendously over the year, and now that we've got most of our code in order, the pace should accelerate still.