add ospp blog (#166)
diff --git a/content/cn/blog/2024/ospp.md b/content/cn/blog/2024/ospp.md
new file mode 100644
index 0000000..5ed58a5
--- /dev/null
+++ b/content/cn/blog/2024/ospp.md
@@ -0,0 +1,40 @@
+---
+title: 2024 开源之夏结束，HoraeDB 参与同学获得最具潜力奖！
+date: 2024-12-26
+tags:
+ - community
+---
+
+[开源之夏](https://summer-ospp.ac.cn/org/orgdetail/44e53042-d59d-4eb1-9195-a8c81c868adc?lang=zh)是由中国科学院软件研究所“开源软件供应链点亮计划”发起并长期支持的一项暑期开源活动，旨在鼓励在校学生积极参与开源软件的开发维护，培养和发掘更多优秀的开发者，促进优秀开源软件社区的蓬勃发展，助力开源软件供应链建设。
+
+2024 年 Apache HoraeDB 共有[两个项目](https://summer-ospp.ac.cn/org/orgdetail/44e53042-d59d-4eb1-9195-a8c81c868adc?lang=zh)匹配成功，并且全都顺利完成！
+
+## 单机版 WAL 实现
+
+WAL 是保证数据可靠性的重要组件，在之前的实现中，采用的是 RocksDB 引擎作为 WAL 的实现，RocksDB 本身是个复杂的组件，基于它来实现 WAL 会有以下问题：
+
+- 编译困难，在 HoraeDB 开发者邮件列表，编译 RocksDB 失败的邮件经常出现
+- RocksDB 自身作为一个完整的 LSM 引擎，本身会有 Compaction、Memtable 等组件，这些组件会带来额外性能损耗，而且调优比较复杂
+ 基于此，我们想设计一个基于本地磁盘的 WAL 实现，去掉 RocksDB 这个依赖。
+
+顾龙同学在实现本地 WAL 的过程中，展现了其较强的代码功底，主要体现在如下几点：
+
+1. 能够独立设计出项目的基本架构
+2. 较强的代码阅读能力，能够在已有项目的基础上，完成新功能的开发
+3. 在性能压测阶段，能够找到正确的方式来发现系统的瓶颈，能提出解决方案，最终达到性能要求
+
+
+
+## 远端合并
+
+Compaction offloading 是数据库在大规模部署的场景下，很有必要支持的一个能力，否则会和对实时性具有高要求的读写节点竞争有限的资源，大幅影响服务稳定性。而要 compaction 模块是 HoraeDB 的核心模块之一，要理解其逻辑，并在此之上进行较大改动，从而支持 compaction offloading 能力是很有挑战性。
+
+苏逸钒同学不但在短时间内就深入了解了 HoraeDB compaction 模块的运行逻辑，而且能通过调研 HBase 等成熟开源项目的类似能力，快速提出在 HoraeDB 支持 compaction offloading 能力的合理方案，并在后续独立实现了方案，展现了其不俗的技术基础、工程能力和学习能力。
+
+更难能可贵的是，苏逸钒同学在此之外，还主动熟悉了 HoraeDB 的核心上游项目 Datafusion，并且快速融入了 Datafusion 社区，因此获得最具潜力奖 🏅
+
+
+
+## 加入我们
+
+通过开源之夏，我们见证了众多优秀学生在开源社区的成长。希望在明年的开源之夏中，能够见到更多优秀的学生开发者在开源的海洋中扬帆起航。如果你也对开源充满热情，渴望在技术的道路上获得更多的历练与成长，我们期待与你相遇！
diff --git a/static/images/2024-ospp-gulong.png b/static/images/2024-ospp-gulong.png
new file mode 100644
index 0000000..c164417
--- /dev/null
+++ b/static/images/2024-ospp-gulong.png
Binary files differ
diff --git a/static/images/2024-ospp-suyifan.png b/static/images/2024-ospp-suyifan.png
new file mode 100644
index 0000000..181bde0
--- /dev/null
+++ b/static/images/2024-ospp-suyifan.png
Binary files differ
