每天打开 GitHub 看首页动态的习惯保持到了现在，突然有一天就注意到了我之前写给自己用的那个看图软件（菠萝看图）连续有了多个 Star，就好奇看了下 Traffic，然后发现竟然有一些网站收录了我的这个软件。于是后续的一段时间就开始偶尔也关注下（GitHub repo 访问的） Traffic，然后发现了一些蛮有趣的事情。其实，我把我这个软件发布出去到现在这个过程都蛮有意思的，于是这篇文章就正好记录下关于我为什么写这个东西出来，以及都有哪些有意思的事情。

当然在开始之前，如果你是通过搜索引擎之类的找到的这个文章，然后只是想获取个下载地址或者源码的话，这里是一些传送门：

此列表外的所有站点页面都不是由我提供的，如果您使用其它来源获取此软件的话，这里不能保证其它来源的可靠性。

起因

最初写我的这个看图工具的时候，我人还在 Deepin，v20 研发初期的疯狂加班阶段。那个阶段的深度看图被新的研发团队重写，初期则有一段时间启动是奇卡无比（因为会阻塞式的加载同目录下其它图片文件的缩略图，从原图的比例压缩尺寸获得的），而我维护我产品过程中偶尔需要看图则不得不用这个奇卡无比的看图来浏览图片文件。一段时间后感觉实在有点受不了了，也加上自己在 Windows 下也并不喜欢 Windows 10 所带的新图片资源查看器，旧的也看不了 GIF 和 SVG，于是决定还是自己写一个给自己用好了，目标也是非常简单，能看包括 SVG 在内的特别常见的图像格式，能正常播放 GIF，能在 Windows 和 Linux 下使用，然后加上我之前其实非常喜欢古董版 QQ 自带的图像查看器那种风格的设计，于是目标的界面也大体基于那个。

如果你但凡了解过一点桌面应用程序开发，应该都不难猜到，写一个简单的图片查看器出来其实要不了多久，也没有多少工作量，以至于其实很多“教程”都会拿写简易图片查看器或者简易音乐播放器之类的当成哈喽沃德来给人练习。然后我也不算 Qt 新手，于是初版没用几天的业余时间就搞出来了。之后则是准备了 Linux 和 Windows 版来给我自己用，虽然也在群里偶尔发过相关的进度截图但也没太当回事——毕竟是完全给自己用的东西嘛。

后来突然有一天，我组的其他组员有请教我一些听上去挺相关的问题，回答后顺带一问问题的场景，才知道同事也想自己写个来用，于是就告诉他我正好写了这么个东西，可以拿来用。然后我就突然觉得似乎并不是只有我会有这种需求，尽管写这么个东西存粹是为了给自己用，但如果能顺带发出去给正好需求和我近似的人用的话，应该也不错，于是就开始有了把这个项目搞正式一些的想法，就开始除了修我自己遇到的问题外，开始把一些地方变得更正规一些，然后开始在 GitHub 打 tag 甚至发 Release 了。

目标和受众

无论这个项目怎么演进，这个项目的第一受众或者用户肯定是我自己。事实上还有一些别的 pineapple- 前缀的应用存在，实质上也都是给我自己用的，于是无论如何都会以我自己的需求为主。把项目搞正式的目的其实也是希望能让更多“和我有相同或相近使用习惯”的人也可以有顺手的软件用，而不是致力于做一个什么别的软件的替代品，而我的需求或者目标大概是这样的：

  • 只读：绝对不会轻易不小心把文件给改掉，任何操作都不会改变文件本身。例子是，Windows 图像查看器会把图像方向信息写回图像的元数据里，这个行为是我蛮不希望做的。
  • 不带图像编辑功能：既然是只读，于是绝对不会提供图像处理的相关功能。如果要有，会是独立的别的程序去做，而不是用图像查看器。
  • 不带图像管理功能：我有我自己组织文件的使用习惯，不希望一个存粹的图像查看器去包含图像管理的功能，因为这种行为很可能和自己的习惯不一样。如果要有，也会是独立的程序去做，而不是图像查看器。

至于已知的受众，除了最初让我意识到不只是我有这种需求的同事（现在应该叫前同事了）外，目前还有卡拉否和码喵。一个在 KDE 下用作图像查看器（和我一样），一个更倾向于利用窗口置顶功能来作为“贴图”工具，把参考图“钉”在桌面顶部，以便和其它软件一同使用。

事实上在我发现网上突然有了我这个应用的索引之前，我并不期望我这个工具能有多少其它用户，后续发现的各大网站收录确实是意外，我也可能会根据反馈进行一些行为调整，但肯定不会改变我自己的这些原始目标。

软件包提交和商店投递

在比较长一段时间的自己使用和常规的调整维护后，我觉得我这个东西差不多到了一个“能用”的程度了，自己做了 CPack 的 debian 包打包，有卡拉否和我家里在用。于是突然有一天就想试一下投递这个应用到 Debian 看看，如果可以的话，大概会有更多的人能获取到这个应用，如果刚好觉得也符合自己的使用习惯的话，就多了个受益者。发送 Debian RFC 邮件请求后的一周后，有维护者表达了维护意愿，并一段时间后真的进入了 Debian unstable 仓库。不得不说当时确实挺高兴，也成了我继续做这个应用的一个动力吧。不过要说起来，我确实不知道为何我的这次 RFC 能在这么短的时间就获得响应——或许是因为我这是个纯 Qt 应用，（当时）没有任何第三方库依赖，维护者看到觉得软件非常好打包？因为我也是 Chris 的 QMidiPlayer 的用户，也希望那个软件可以进 Debian 仓库，不过那个软件的 RFC 就没有像我那个应用一样很快有维护者表示维护意愿…

至于 itch.io 商店的提交，则是另一个目的了。码喵之前提到希望软件具备自动更新的能力，尽管做这么个功能出来其实也挺简单，但其实我觉得软件自身带这个功能其实不合适，这个事情应当是商店或者包管理器来做，或者至少是个单独负责软件更新的工具来做。于是就选了 itch.io 商店，一方面能有个软件“首页”，一方面能通过官方的客户端检查更新和自动更新。

除了 itch.io 和 Debian 之外，就没再投递过其它位置了，于是实际的“官方”获取途径就只有 GitHub Release，Debian 仓库，Archlinux AUR，itch.io 对应页面，以及 Gitee 镜像。其它之外的地方，预期之内的大概就只有基于 Debian 的发行版同步 Debian 仓库的时候会有，这个在 Repology 其实可以查到，至于后续发现有其它软件分享论坛和网站可以看到我的看图应用，就是另一回事了。

写它有没有意义

其实写它的整个目的本身就是方便我自己用的，所以自然是有意义的，而后续维护，完善，则是和上面说的一样，希望方便我的同时也可以方便和我需求相近的人。当然，除此之外，在软件的维护过程中，其实也有做一些别的我觉得多少有意义的事情。

例如，我的 Windows 版本使用了 KDE 的 kimageformats 组件来提供包含 PSD 格式在内的图像格式支持，而偶然发现我的一些 PSD 文件并没有正常显示之后，对着源码挂调试定位了一下，发现是 kimageformats 的 PSD 格式支持并不完整，实际上 KDE 下使用别的同样基于 kimageformats 来查看 PSD 格式的应用的话，也是没法正常载入的。存粹是为了自己的需求，于是决定处理一下这个问题，给 kimageformats 追加了 16-bit per channel (A)RGB 格式的支持，并最终顺利的合并到了 kimageformats 的主线。于是即便不使用我这个看图工具的人，如果使用 KDE 并希望浏览 PSD，还是可能同时受益的。

另外则是后来在（新）公司发现 Windows 版开 WSL2 下的图片会打不开，定位后发现是 Qt 本身的问题。当时看着问题其实不难处理，但因为不在 D 司了，准备环境改 patch 然后提交到 Qt 相对还是比较麻烦的，于是也没有太大意愿去主动改这个 patch，就开了个 BUG。后续 Qt 在 5.15.2 包含了这个 BUG 的修复，于是 Qt 用户大概也会因此受益吧。

这么来看的话，无论是从提供软件还是提供到上游的缺陷修复来看，至少都是会有人受益的，所以我觉得，反正这也不是个大项目，能满足自己需求的情况也能使得更多人受益的话，也没什么不好的不是么？

其它站点收录

但其实导致我打算写这篇的原因，其实是后续被发现陆陆续续有一些网站和论坛开始收录这个软件了，甚至我都没有摸清楚到底是怎么突然开始传播的。一开始猜测是 itch.io 引来的流量，但观察 itch.io 后台后感觉应该不会是 itch.io，而 GitHub 也不像，毕竟之前也有一些别的东西，偏偏这个后来突然就有了流量也不对劲…

最初发现是 Softpedia 收录了软件，写了一篇蛮有趣的评测。后续则发现在神奇毛子的论坛的一个“图像查看器投票帖”里有人贴链接（尽管不清楚是不是只是搜到随手贴的性质）。后续的一段时间就偶尔会看到来自这两个网站的 traffic。然后突然有一天，竟然发现突然开始涨 Star 了，再度留意 traffic 则发现是另外两个网站也分别评测和推荐了这个软件。这些网站分别都写了自己独立的评测，我觉得也没什么问题。

后续发现事情开始变得有意思是发现 Star 的用户开始出现了国内用户，而我显然没做过国内的宣传之类，于是继续观察 traffic，则发现有一些国内“资源共享”网站开始收录了这个软件。挂引号则是因为其实本身是盗版网站，然后看了看内容描述则是 softpedia 评测的机翻（包括我应用内文案原本有中文，实际写的也是英文机翻到中文的文字…），此后突然好奇，于是就谷歌了一下“菠萝看图”，然后发现除了 traffic 页面列出的网站之外，也有其它一大堆中文盗版软件站收录了这个应用，其中甚至不乏故意给版本号最后一位加个一然后骗取用户下载的站点。为了不给这些站点引来流量，这里就不再给出链接了…

国内倒是也有用户/自媒体自己认真写评测来推荐这个应用的，其实我也不反对合理转载，既然选了 Expat/MIT 这个非常宽松的协议，就不会反对遵循协议范围内的使用。而观察到各大“软件共享”站点爬取其它网站内容来收录，则觉得还是有点惋惜国内的网络质量。

不知道你有没有遇到过搜索技术问题时，有一大票的搜索结果是中文网站爬取 StackOverflow 机翻的网页，如果有的话，不知道你是不是和我一样厌恶这种性质的网站存在。爬虫技术不是什么坏技术，但这样的应用方式着实让人觉得恶心。

从 Transifex 到 Weblate

D 司的所有应用都使用了 Transifex 作为平台进行本地化，相比其它的各大翻译平台，Transifex 的“好处”则大概在于，只要你有账号，能在 GitHub 开 repo，就能使用 Transifex 的服务了，而其它各大平台尽管也都有开源项目的免费翻译托管服务，但都需要人工审核。于是出于方便起见，我自己的一些 repo 也是直接使用了 Transifex 进行本地化，但与其说使用了 Transifex，不如说其实和没用一样。

让其他人参与 Transifex 协作大概是个很蛋疼的事情，外部贡献者需要加入你的翻译团队之后才能参与实际的协作，而加入团队则需要审核，于是对于我这种非常小规模并且万年估计才能等来一两个协作者的 proj，大概这种门槛会导致潜在贡献者放弃贡献，以及即便点了申请加入团队，你也得频繁登陆 Transifex 才会看到别人的请求。

Transifex 的另一个问题则在于，别人申请加入团队时，自己是没法设置一些预显示的公告或者文字的，即便加入后也不会显示。于是假如我希望贡献者在翻译之前明确知道翻译会以什么许可进行授权使用之类的问题，则没法轻易的标明了。

于是，在上面意识到突然有了外部引入的流量后，我开始抱着试一试的心里申请了 Weblate 的翻译托管服务，然后发现体验确实比预期好很多。一方面它允许我标明翻译所使用的许可，也允许我设置额外的内容来让译者在开始贡献前就明确许可（比如 CLA，尽管我没设，毕竟已经可以明确标明是 MIT 许可了），另一方面参与翻译不再需要等我“审核并同意”就可以直接协作。

Weblate 官方实例注册并创建项目后会有大概半个月的体验时间，可以在这个阶段试用并考虑购买或申请自由软件的免费托管服务，我注册后完成配置和一些检查项后就填写了申请开始等，而就在第二天，就开始收到几个语言的添加和别人贡献的翻译了，确实是我蛮意外的。Weblate 的官方实例上也有不少其它自由软件项目，包括 Godot Engine 以及 Zrythm 之类的都在里面，这个列表所有人也可以很轻松的浏览到，大概是因此有人提交了翻译吧。我提交自由软件项目托管后的大概一周左右时间，申请通过了，相对还不错的使用体验加上确实更健康的社区生态，于是也就决定继续用下去了。

其它杂话

尽管这个看图应用现在似乎有了越来越多的用户，但目前而言，我还是会以我自己的使用情况为主进行开发和完善，大概不会随便做出妥协来调整交互方式和设计之类。无论是自由软件还是专有软件，“市面上”最不缺的大概就是看图类应用了，现在其实也有一些社区驱动开发的看图应用项目，如果我的看图工具不能满足你的需求的话，如果现在本身就存在与你需求更近似的其它应用，我个人还是建议你直接用其它的。如果有人提的建议刚好属于我能接受的范畴（大概就是上面“我的需求或者目标”里提到的那些）的话，兴许也会加。

这个软件所选的许可协议是 Expat/MIT，并非 copyleft 许可。选择宽松许可的目的就是希望当你确实需要时，可以拿着去改到符合你需要的情况来用，然后给予尽可能少的约束。我会尽可能保持应用本身符合我自己的使用需求，故别人提出的修改建议肯定有一些会被我拒绝，但这个许可证意味着你仍然有自己动手修改使其满足需求的自由，甚至允许你闭源再发布。

至于应用名称带 pineapple- 前缀则也是一个比较刻意的做法，应用程序的（给人看的）名称就被分成了这个前缀以及剩下的后半部分这两部分，后半部分直接对应了应用程序本身是干嘛的，前半部分则表示是我做的。由于具备这个前缀的应用显然都是我个人维护的应用，故如果有人真的打算拿来自己修改的话，大概也很可能希望给程序也改个名字，这样就能和我所提供的版本予以区分了。

顺带一提，从上面的描述你肯定可以看出来，这个项目（包括其它 pineapple- 前缀的项目）显然会是我个人主导开发的，而不会是社区驱动开发的，也不会在将来成为社区项目。我个人其实完全不反感社区项目，但社区项目就意味着是社区大众来商讨决定项目的后续开发方式，包括怎么开发，程序后续要包含什么功能，etc，而我的初衷就完全只是“给我自己用的用的趁手的工具”而已。如果，我是说如果，真的有那么一天，我的工具会有一定数量的人喜欢并希望社区可以主导开发，我会希望社区能派生并维护一个社区驱动的版本出来，甚至改掉前缀，如果有这么一天的话，我也会很乐意在能帮上忙的情况下给予帮助…

…然后我仍然会维护我自己的版本来给我自己用。

惯例：2021年1月3日，00点19分。