Kawa future and governance

Kawa future and governance

[Per Bothner]

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 (https://domterm.org).
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
per@bothner.com   http://per.bothner.com/

Re: Kawa future and governance

[Lassi Kortela]

> 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.

Your criticism is on point. We have definitely bit off more than we can 
chew this year. With so much work to do by a few volunteers, mistakes 
have been made, and will be made.

> 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.

A coherent vision is the only known defense against complexity getting 
out of hand as a system grows so you have made a good trade-off, and it 
shows. It's a heroic effort for one man as it is.

> 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.

A major accomplishment indeed. Congratulations, and a thank you for 
sticking with it all these years!

If only we could advertise this feat to more people. It's tricky to get 
people to believe that Schemers do such excellent work to no fanfare.

> Thoughts?  Volunteers?

Your plans all sound very reasonable. I'll continue to make sure my 
stuff runs on Kawa, and can help with individual features now and then.

Re: Kawa future and governance

[Duncan Mak]

I'm definitely interested in contributing where I can!

On Mon, Nov 9, 2020 at 12:13 PM Per Bothner <per@bothner.com> wrote:

> 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 (
> https://domterm.org).
> 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
> per@bothner.com   http://per.bothner.com/
>


-- 
Duncan.

Re: Kawa future and governance

[Jamison Hope]

Count me in, too.

-J

On Mon, Nov 9, 2020 at 5:04 PM Duncan Mak via Kawa <kawa@sourceware.org>
wrote:

> I'm definitely interested in contributing where I can!
>
> On Mon, Nov 9, 2020 at 12:13 PM Per Bothner <per@bothner.com> wrote:
>
> > 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 (
> > https://domterm.org).
> > 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
> > per@bothner.com   http://per.bothner.com/
> >
>
>
> --
> Duncan.
>
-- 
Jamison Hope

Re: Kawa future and governance

[Damien MATTEI]

i appreciate Kawa a lot and

i'm interested too in contributing.

Damien

Le 12/11/2020 à 06:39, Jamison Hope a écrit :
> Count me in, too.
>
> -J
>
> On Mon, Nov 9, 2020 at 5:04 PM Duncan Mak via Kawa <kawa@sourceware.org>
> wrote:
>
>> I'm definitely interested in contributing where I can!
>>
>> On Mon, Nov 9, 2020 at 12:13 PM Per Bothner <per@bothner.com> wrote:
>>
>>> 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 (
>>> https://domterm.org).
>>> 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
>>> per@bothner.com   http://per.bothner.com/
>>>
>>
>> --
>> Duncan.
>>

Re: Kawa future and governance

[Helmut Eller]

On Mon, Nov 09 2020, Per Bothner wrote:

> 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.

Apparently you have the copyright on most of Kawa's code.  Would
contributors have to assign copyrights if they change something?

Helmut

Re: Kawa future and governance

[Per Bothner]

On 11/14/20 10:11 AM, Helmut Eller via Kawa wrote:
> On Mon, Nov 09 2020, Per Bothner wrote:
> 
>> 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.
> 
> Apparently you have the copyright on most of Kawa's code.

Yep - because I wrote most of it.

> Would contributors have to assign copyrights if they change something?

I have not required copyright assignments.  My informal policy is if a file is
substantially the work of one person, only that person is credited with
a copyright note in the file.  If multiple people have contributed substantially
(say 20%) they should be listed too.  A change/fix of a few lines does not
get copyright credit.

But this is more about openness and giving credit where due.  Legally what
matters is the license.  All contributions must be compatible with the
appropriate license.  New files must be compatible with the overall (software or
documentation) license, and changes to existing files must preserve the license
of the file (unless those listed in the copyright agree).
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Re: Kawa future and governance

[Andrija Vranić]

I said it, but one more time: as a beginner I am willing  to be put to use
for any task I can help with!
Cheers,
Andrija

On Sat, 14 Nov 2020 at 20:33, Per Bothner <per@bothner.com> wrote:

> On 11/14/20 10:11 AM, Helmut Eller via Kawa wrote:
> > On Mon, Nov 09 2020, Per Bothner wrote:
> >
> >> 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.
> >
> > Apparently you have the copyright on most of Kawa's code.
>
> Yep - because I wrote most of it.
>
> > Would contributors have to assign copyrights if they change something?
>
> I have not required copyright assignments.  My informal policy is if a
> file is
> substantially the work of one person, only that person is credited with
> a copyright note in the file.  If multiple people have contributed
> substantially
> (say 20%) they should be listed too.  A change/fix of a few lines does not
> get copyright credit.
>
> But this is more about openness and giving credit where due.  Legally what
> matters is the license.  All contributions must be compatible with the
> appropriate license.  New files must be compatible with the overall
> (software or
> documentation) license, and changes to existing files must preserve the
> license
> of the file (unless those listed in the copyright agree).
> --
>         --Per Bothner
> per@bothner.com   http://per.bothner.com/
>