Skip to content

Commit 7c79a98

Browse files
dmikurubedmikurube
committed
Article: Embulk into the "maintenance mode"
1 parent 17d9d51 commit 7c79a98

1 file changed

Lines changed: 160 additions & 0 deletions

File tree

‎_posts/2025-11-10-embulk-into-the-maintenance-mode.md‎

Lines changed: 160 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,160 @@
1+
---
2+
layout: posts
3+
title: Embulk into the "maintenance mode"
4+
date: 2025-11-10
5+
description: "The Embulk project is going into the maintenance mode. Please do not expect that Embulk will be maintained actively. Even if you submit a pull request to the Embulk project, it may not be reviewed nor merged."
6+
author: "dmikurube"
7+
---
8+
9+
On October 15, 2025, I sent the following email to those who were in the GitHub organization: [https://github.com/embulk](https://github.com/embulk)
10+
11+
```
12+
(... snip: greetings in Japanese ...)
13+
14+
15+
To all who have been or are involved in Embulk, and who belong to Embulk's GitHub
16+
organization,
17+
18+
I'm sending this email to addresses confirmed publicly in Embulk-related git log,
19+
or addresses confirmed individually.
20+
21+
The English message follows the Japanese part.
22+
23+
24+
(... snip: the message in Japanese ...)
25+
26+
27+
Long time no see. This is Dai.
28+
29+
30+
You might have seen some recent topics about RubyGems closely.
31+
32+
https://rubycentral.org/news/rubygems-org-aws-root-access-event-september-2025/
33+
https://andre.arko.net/2025/10/09/the-rubygems-security-incident/
34+
35+
I do not know what is correct or who is at fault, and I am not in a position to
36+
comment on it.
37+
38+
39+
However, I feel that the biggest lesson we should learn from this case is:
40+
"In an open-source project involving multiple stakeholders, we should establish
41+
and formalize clear project governance that reflects the reality, while the community
42+
can still discuss it peacefully and democratically — **before** such issues arise."
43+
44+
"Especially when security is a significant concern there, or when money and/or
45+
for-profit company(s) are involved."
46+
47+
48+
As for the open-source project Embulk, I too have stepped down, and already been
49+
inactive as a maintainer. The situation has been like "we have no active maintainers"
50+
for about six months already.
51+
52+
https://www.embulk.org/articles/2025/04/11/dmikurube-is-stepping-down.html
53+
54+
55+
In Embulk, now, the (even though inactive) "maintainers" are practically:
56+
* Only I and Sato-san are looking at the areas close to the Embulk core.
57+
* We sometimes ask @hito4_t -san to take a look at JDBC-related things.
58+
* Along with them, embulk-output-bigquery has a couple of its own independent
59+
maintainers.
60+
61+
62+
When I was still at Treasure Data, I was doing some governance and administrative
63+
actions such as establishing the Core Team entity as a form of governance, and
64+
removing some individuals (including some in-TD and ex-TD persons) from the GitHub
65+
organization after some communications when they weren't actively participating in
66+
the community.
67+
68+
I, however, have left TD, and became inactive as a maintainer. It is getting harder
69+
for me to continue such governance and administrative actions with confidence —
70+
especially with many inactive members in the GitHub organization.
71+
72+
If the situation continues for a couple more years, it wouldn't be surprising to see
73+
a problem similar to the RubyGems case mentioned at the top of this email.
74+
(Embulk is not depended on by so many users like RubyGems, though.)
75+
76+
77+
The maintenance of Embulk has already been almost suspended in practice, although
78+
it appears to be continuing on the surface. For example, even if a security-related
79+
report comes to us, it would be hard for us to handle it timely and properly.
80+
81+
82+
Therefore, in order to "establish and formalize clear project governance that
83+
reflects the reality, while the community can still discuss it peacefully and
84+
democratically," I think about transitioning Embulk into the "maintenance mode"
85+
roughly with the following measures:
86+
87+
1. Minimize the GitHub organization and the Core Team members to only "those who are
88+
willing to continue participating to some extent going forward".
89+
* What we want for "those who are willing to continue participating to some
90+
extent going forward" would be just "showing your membership, name and
91+
affiliation publicly in the GitHub organization" and "willing to spend a
92+
dedicated time as one of the responsible members in the party when
93+
something happens and discussions are needed".
94+
* I guess, however, you already know that even only these are still hard.
95+
2. Agree that "we can no longer continue managing this project actively" among the
96+
remaining members.
97+
3. Reduce the scope of what we need to manage (ex. Zulip chat).
98+
4. When someone raises their hand to take over Embulk, discuss it among the
99+
remaining members.
100+
5. Declare the "maintenance mode" with these measures above, and announce it to
101+
the public.
102+
* I think about containing this email itself, almost as-is, in the announcement
103+
at https://embulk.org/ and else.
104+
105+
106+
What do you think?
107+
108+
I'd appreciate it if you could share your thoughts and/or indicate your intention
109+
whether you wish to remain involved or not, as a response to this email.
110+
(If needed, you could respond only to me.)
111+
112+
I believe that it'd be best to take action after receiving some form of response
113+
from everyone. However, if I receive no response from someone by the end of this
114+
month, October 2025, I'll interpret it as meaning "no intention to remain involved",
115+
and proceed accordingly.
116+
117+
118+
Thank you very much for your understanding and cooperation.
119+
```
120+
121+
(*) Please note that the Bundler/RubyGems case mentioned in the email was concluded on October 17, 2025. See: ["The Transition of RubyGems Repository Ownership"](https://www.ruby-lang.org/en/news/2025/10/17/rubygems-repository-transition/)
122+
123+
What is happening?
124+
===================
125+
126+
As stated in the email, the Embulk project is going into the "maintenance mode" with the following measures.
127+
128+
1. The Embulk GitHub organization [https://github.com/embulk](https://github.com/embulk) is going to have only the minimum belonging members who are willing to continue participating.
129+
2. The Embulk team is going to reduce the things that need to be managed. For example, the Zulip chat for Embulk developers will shut down.
130+
3. The Embulk team declares the maintenance mode, which means that "we can no longer continue managing this project actively".
131+
132+
Long story short, please do not expect that Embulk will be maintained actively. Even if you submit a pull request to the Embulk project, it may not be reviewed nor merged. As Embulk has been licensed under [the Apache License, Version 2.0](https://www.apache.org/licenses/LICENSE-2.0), such maintenance has never been guaranteed, though.
133+
134+
Who is going to stay in the organization?
135+
==========================================
136+
137+
Finally, we received responses to my email from 10 members out of 18 recipients (including Bcc'ed) before the end of October 2025. Based on their responses (or lack thereof), only the following four individuals will remain in the Embulk GitHub organization.
138+
139+
- [@frsyuki](https://github.com/frsyuki), the original creator
140+
- [@hito4t](https://github.com/hito4t)
141+
- [@hiroyuki-sato](https://github.com/hiroyuki-sato)
142+
- [@dmikurube](https://github.com/dmikurube), the author of this announcement
143+
144+
Will Embulk never be updated or maintained?
145+
============================================
146+
147+
I won't say "never". We may update Embulk if we feel inclined to do so. That said, please do not expect it.
148+
149+
We may do just some minor tidy-ups and clean-ups. However, a major update does not seem realistic, such as catching up with future versions of Java, or upgrading incompatible dependencies like [Jackson 2 to 3](https://github.com/FasterXML/jackson/wiki/Jackson-Release-3.0).
150+
151+
Alternatively, if someone raises their hand to take over Embulk, as stated in the email, the remaining members will discuss it. However, I personally do not expect that to happen, as we have not received any good proposals in response to the following announcement from last year: [Looking for long-term maintainers around the Embulk eco-system](https://www.embulk.org/articles/2024/11/28/looking-for-long-term-maintainers.html)
152+
153+
Please understand that declining a takeover proposal from someone who is completely new to the community could actually be better for users. As you may know, Embulk has been used to transfer sensitive data within some organizations. What if Embulk were handed over to someone with malicious intent? Simply declining such a proposal and discontinuing the project could actually be the better option. Taking over is not easy.
154+
155+
Conclusion
156+
===========
157+
158+
I believe that Embulk has fulfilled its role. It was a good opportunity for me personally to take over and maintain Embulk over the years.
159+
160+
Thanks to Sada for creating Embulk, and thank you everyone who has been involved in the community!

0 commit comments

Comments
 (0)