public inbox for
 help / color / mirror / Atom feed
From: Per Bothner <>
To: Kawa mailing list <>
Subject: Kawa future and governance
Date: Mon, 9 Nov 2020 09:06:16 -0800	[thread overview]
Message-ID: <> (raw)

As you have probably noticed, there has been less Kawa development the last
few years, and I have been less active.  I make sure it will work with
newer Java release, fix occasional bugs, and make minor improvements,
but it's been a while since I've added a new non-trivial feature or API.
Most of my "hacking time" these days is spent on DomTerm (
I'm also less involved with the Scheme community, and I've expressed
dissatisfaction with how SRFI and R7RS-large is evolving, with
too many large large APIs that I fear will see little use.

I am happy to continue in this "maintenance mode" as long as needed,
but fresh blood would be welcome.  So far Kawa has is mostly the result
of my vision, opinions, and prejudices, which I think has resulted in
a coherent, efficient, and powerful language - but it is limited what
I can understand and implement.  It is great what others have contributed
to Kawa, but we need to encourage and enable more contributions  I have
not been as open as I should have to other ideas and impulses, wanting
to full understand and implement the "right" solution, even when I have
lacked time, knowledge, and energy to do so.

Not sure where to go next.  It would be good to have a small group
who can check in updates and make releases without me.  Right now the
Kawa "bus factor" is basically one, which is not a good situation.
I can see my role becoming a Benevolent Dictator For Life (like van
Rossum's role in Python), but ideally getting less dictatorial as others
gain experience.

One task that could help and that does not require comprehensive understanding
of the code is Release Manager(s).  Not that it takes a lot of time and effort
to make a release (especially since I don't do it very often), but it is one
of multiple tasks that should not depend on me being able to do it.

Next year Kawa will be 25 years old.  It is the oldest continuously-active
compiler-based non-Java language on the JVM, which is quite an achievement.
But I am not getting any younger, and it needs fresh blood and energy.

Thoughts?  Volunteers?
	--Per Bothner

             reply	other threads:[~2020-11-09 17:06 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-09 17:06 Per Bothner [this message]
2020-11-09 17:40 ` Lassi Kortela
2020-11-09 22:03 ` Duncan Mak
2020-11-12  5:39   ` Jamison Hope
2020-11-13 18:27     ` Damien MATTEI
2020-11-14 18:11 ` Helmut Eller
2020-11-14 18:53   ` Per Bothner
2020-11-15  8:51     ` Andrija Vranić

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).