The Raku Foundation

[ash]

TL;DR

We have to establish the Raku Foundation (TRF).

What

The most obvious things TRF is responsible for:

• Keeping the trademark
• Covering expenses for the working ecosystem
• Funding Raku (and related tools) development
• Working with sponsors
• Organising Raku events (global or EU + US)
• Participating and/or initiating participation in other IT events (e.g., FOSDEM)
• Making proper language promotion
• Thinking of job marketplace
• Other minor branding things such as merchandise items.

Why

A separate business unit is needed to make Raku independent of The Perl Foundation and of Perl itself. In my opinion, continuing being just ”a member of the Perl family” is against our interests to make Raku a strong language.

As for the financial stuff, I want better transparency comparing to what we have now with TPF. We see no proper reports and we have no idea of how much the “Raku fund“ has on its account. Neither the sponsors get a clear understanding of what they are paying for. Neither there is good exposure for them.

Finally, it is not correct that some decisions are taken by non-Raku people.

How

Well, it is said "Do not propose a solution" in the issue :-) But seriously, that's a serious question. Do we have a EU fund, or do we make a US-based unit, or do we hire bookkeepers, etc. Let me not list all those right away. That's a thing much more difficult than a single Raku conference.

[duncand]

@ash

I weakly support having two separate arms-length foundations in principle. While we lose some efficiency of scale, see the Apache Foundation as a counter-example of one org managing distinct projects, separate orgs also more clearly allow individual focus on each language more than anything else.

In order for this proposal to have serious traction, it will need to lay out important details of what each separate organization would look like.

In particular, this proposal needs to lay out who would be running the separate organizations. We need to know that there are enough people willing and capable of stepping up for all the roles running the separate organizations would require. Everything else such as splitting the money is relatively simple.

So what roles is the new foundation going to need and who is willing to take those roles for at least a few years?

This proposal is dead on arrival without that being answered first.

[Leont]

In particular, this proposal needs to lay out who would be running the separate organizations. We need to know that there are enough people willing and capable of stepping up for all the roles running the separate organizations would require.

This proposal is dead on arrival without that being answered first.

Running a foundation is a thankless job. Even for TPF it's hard to find the right people, and they have a much bigger pool to fish from. I'm skeptical about this part.

[lizmat]

In my opinion, continuing being just ”a member of the Perl family” is against our interests to make Raku a strong language.

I agree. Now, whether a Raku Foundation would be another shim for YAS (like The Perl Foundation is), or a real thing, that is a question that needs answering.

YAS now has had the chance of creating another "doing-business-as" called the Raku Foundation. But it hasn't happened yet. And I've seen no signs of this happening any time soon. Having The Raku Foundation as another name for YAS, would at least help with the PR. The fact that all Raku grant requests / reports are still published on a "Perl" site, just continues to be bad PR for Raku.

I want better transparency comparing to what we have now with TPF. We see no proper reports and we have no idea of how much the “Raku fund“ has on its account

I agree with this as well.

Now, as one of the people who originally founded The YAPC::Europe Foundation (and still legally president of that), I know from personal experience how hard it is to keep such a thing going. I'm willing to help anybody who would like to go ahead with making a proper Raku Foundation. But first we need to get clarity from YAS about the idea of creating another dba. If this does not materialize before the next conference in the cloud, I'd say it is clear it is not going to happen. And we should start thinking about alternatives.

[duncand]

The way I figure it, if the Raku community is large enough to sustain having its own foundation, it will contain enough people willing and able to step up and take the job of running said foundation; and if there aren't enough stepping up, that indicates the Raku community isn't large or independent enough to have its own foundation and continuing to share with Yet Another Society makes more sense. Or perhaps the Raku community, if not able to stand on their own with a foundation, might want to approach the Apache foundation or some other generic one to be served by, if they think that would work better than Yet Another Society. I'm not advocating any particular solution, but just pointing out alternatives.

[codesections]

I'll add a +1 to all the people in this issue saying that it would be nice to have the name "The Raku Foundation" as an alias/DBA/shim for YAS. It would certainly simplify naming conversations, and more accurately reflect reality.

However, I would be extremely hesitant to support creating a separate Raku Foundation any time in the near future. Keeping all of the pieces moving for something like YAS takes a tremendous – and often severely underappreciated – amount of work. I've gotten a small first-hand look at the amount of effort YAS puts into keeping the ship running, and I know from many similar groups how time consuming that work can be.

From my point of view, the question isn't whether the Raku community is large enough to support a Raku Foundation – I'm sure we could, if we needed to. The question is whether doing the hard work of running our own foundation has benefits that would outweigh the significant costs. To say the same thing more concretely: if we needed to run our own foundation, I would be willing to pitch in. But, given the sadly limited nature of hours in the day, any time I spent on the hypothetical foundation would be time taken away from contributing to the Raku ecosystem in other ways (PRs, modules, blog posts, Stack Overflow answers, etc). And I bet the same is true for anyone else we'd want in the hypothetical foundation.

Or, to express myself in bummer-sticker terms: We could start our own foundation, but I'd rather be coding.

[lizmat]

We could start our own foundation, but I'd rather be coding.

That, in a nutshell, describes the conundrum. :-)

[nige123]

I favour a new DBA for the TPF that is not Perl-specific: "The Artistic Software Foundation" or even "Yet Another Society".

This means not splitting the limited resources of running the TPF. It also gives room for growth to support other software projects (should they want support).

The Apache Software Foundation is a good model for TPF - it's possible to support more than one project.

As I understand it TPF is working towards more transparency in regards to donations etc - it should be possible to account clearly for separate project donations etc.

[jjn1056]

Perl is facing an existential crisis. Jobs are drying up, most companies using Perl consider it legacy and SDK support is non existent. Programmers outside Perl regularly mock our language and many programmers working at companies using Perl either endure harassment and neglect from their peers or have to hide the fact that they are doing so to avoid the CTO shutting them down. Their careers are pigeonholed. As a consultant I hear time and again from my clients that they want to get Perl out of their systems because it’s obsolete, impossible to hire for and just plain a bad language to use. My statements here are not hyperbole. Yes, Perl has always had to deal with its detractors, even back in the mid 1990s when it was popular. But the last 5 years seem have to reached a tipping point. Nearly all younger programmers that come into the field from academia loath Perl. This is a real problem. What we need is a leadership that is singularly focused on solving this problem. Not one that has split loyalties. The only way to achieve this and show profession Perl programmers its Foundation is serious about addressing their needs is thru a strong, independent foundation. The existing community is too small and too underfunded to support more than one language in any case. Therefore I support splitting the Perl Foundation and allowing Raku to form its own, independent identity.

[nige123]

@jjn1056 - I agree that Perl is facing an existential crisis - and I have also experienced a lot of what you describe.

There is a serious branding vacuum around Perl - and sadly there has been for a very long time. This allowed other competing languages to apply stickers like 'dead', 'write only' etc. This is a problem that existed pre-Raku.

The way to turn around the fortunes of Perl is to finally create an authentic brand stack - and for the community to get 100% behind it. TPF (or whatever organisation) can only play a small part in this - the community will need to rally behind what Perl stands for, communicate it to CTO's etc and stand by it.

At this point expending the energy to split the TPF is like rearranging the deck chairs on the Titanic. The main challenge is to differentiate Perl from Java, Python, Ruby, PHP, GoLang, Typescript etc. Differentiating Perl from Raku is a much lower priority.

Fortunately building an authentic brand stack is not too difficult. What are the top three distinctive values for Perl 7? The messages that embody these values and the truth about Perl is what CTOs need to hear. There's no reason why this all can't happen in 2021. The community will need to finally own its brand - this problem can't be outsourced to TPF. TPF is there to help but the community will need to rally behind these values and communicate them.

Incidentally, Raku also has a branding problem - it needs clear values - clear messages and a plan for the early adopters it will focus on and how to reach them.

[dnmfarrell]

The way to turn around the fortunes of Perl is to finally create an authentic brand stack - and for the community to get 100% behind it. TPF (or whatever organisation) can only play a small part in this - the community will need to rally behind what Perl stands for, communicate it to CTO's etc and stand by it.

No amount of branding or marketing will make Perl relevant again. The perception that it is a fuddy-duddy language stuck in the 90s is largely correct. The only thing that will fix this is improving Perl. TPF's focus should be figuring out where Perl falls short in the marketplace, working with the community to define a vision for Perl, and securing funding for that vision. Then TPF will have something meaningful to promote.

[nxadm]

I am not saying that a Raku foundation would be easy of even realistic at the moment (it may or may not), but a de facto Perl foundation umbrella, under whatever name, is clearly problematic for Raku and in my view also for future Perl.

There are certainly many people that care about both communities, but there are also many that only feel connected to one of the two. And being two distinct languages, that is OK. Despite the declining popularity of Perl, it is undoubtedly a bigger community/ecosystem than Raku. Perl has a rich history and a bigger mindshare in the programming world (both positive and negative). Can we demand of people running a Perl foundation to care about Raku? I don't think so. Great if they do, understandable if they don't.

Perl set itself a dangerous deadline called Perl 7. If nothing comes of it, it will be a PR nightmare and speed up the decline. If Perl 7 is a success, what I sincerely hope, why would the Perl foundation promote a language like Raku that, besides its weak points, already has all the features that people wish Perl 7 had? That would only dillute the message of Perl 7 in a already crowded space.

2c etc

[muriloreis3]

I'm new around here, but much of what is said about branding and marketing is true, and I know that it may seems that doing those things takes time out of coding, but is necessary for the language to thrive, after all with a bigger community and maybe some sponsors a lot more can be done.

[codesections]

I know that it may seems that doing those things takes time out of coding, but is necessary for the language to thrive

I'm not to what extent this was a reply to the bumper-sticker "I'd rather be coding" version of my comment above, but I thought I'd reply to make sure not to give a misleading impression of my views. I absolutely agree that that sort of work is essential for a language to thrive; if I didn't, I certainly wouldn't spend my time serving on the Raku Steering Council and the YAS Legal Committee. I wouldn't participate in the monthly community leaders meetings, or discuss marketing issues in the YAS chat channel. But I do all those things, because I know that the non-code factors do make a big difference.

But precisely because I do spend time doing (a small bit of) that work, I understand just how much work it takes. If it's work that needs to be done for our language(s) to thrive, then I'm willing to do my share. But if the work to enable our languages to grow is already getting done with one organization, I'm very reluctant to split off and duplicate that work. (And I say "duplicate" because the work is so essential; just letting it slide isn't an option.)

[muriloreis3]

I'm sorry if my comment sounded bad, I was trying to make a point that as a bunch of programmers we are not the best at these things, my brother is a designer and he worked with marketing and branding, and when i showed and talked to him about raku and showed the website, it was hard for him to understand exactly what is about and how was marketable

[vrurg]

The arguments in favor of a separate entity so far are more convincing. Yet, the pragmatist inside me is coolingly reasonable: until we get as many volunteers, as it takes to run TRF, ready, it would make more sense for the DBA approach.

[djzort]

Might I offer 2c as someone who loves Perl and wishes Raku all the best.

There is a 3rd option beyond stay with TPF/YAS or BYO Foundation, which is to join another foundation.

Please don't interpret that as an attack or smudge on the people involved with TPF/YAS, but please also hear me out.

Objectively, as a project looking to evolve would it look to TPF or another foundation? Be that the Apache Foundation (like SpamAssassin), OW2 (like LemonLDAP::NG), the Software Freedom Conservancy (like Git, Mercurial, OpenWRT, Samba, Wine) etc

What are the criteria for the supporting organization and how can possible orgs be assessed?

[fixed some typos]

[akuks]

There is no doubt that Perl is on the decline. And then there is Raku, I am not sure how many companies are using it in production.

We are failing to convince newbies to learn Perl. We are failing to convince Data Analyst to use Perl. Despite, In filtering data and regex it is still a language to beat. So the question is, how we convince them to learn or use Raku.

TPF and TRF should focus on attracting new talent and promote Perl in particularly hot domains (like ML, AI, and Data Analysis) but under a separate umbrella.

In my opinion, split the Perl and Raku Foundation and let them struggle independently.

[patrickbkr]

tl;dr Let's not create a new legal entity. Lets create our own The Raku Foundation DBA (doing business as). Mind the ROI.

I think there are two separate benefits we can aim at when we talk about creating a separate legal entity:

Public perception

To create the perception of a separate foundation we don't actually need a new legal entity. We only need a new website that says "The Raku Foundation" and presents itself as such. It can have it's own support / sponsorship page listing a YAS account. (Conveniently YAS has no "Perl" in it's name.) We are in the process of organizing our own conference and I think there is no reason why we shouldn't be allowed to design and create merchandise ourselves.

Be able to freely take our own decisions

I think that the limiting factor of a shared legal entity is rather small. We already have the RSC that can take bold and fast decisions if needed. (Maybe I miss something, but) I think the only aspect where we really depend on YAS is the fund money. But given it is already in a separate pot, what hinders us to mostly decide ourselves how it's spent ourselves?

So all in all I think we shouldn't create a new legal entity. Let's just keep things rolling and invest our time where we have a direct benefit. Maybe by presenting a Raku Foundation to the world.

[ash]

@duncand, @nige123 The Apache's main product, a web server, is way behind its much better alternative, nginx. So, to my opinion, that's not an example of a good organisation for a successful product.

@nige123 It is not quite clear why Raku must still be on the Titanic. "Differentiating Perl from Raku is a much lower priority" is not a high priority indeed, but not a high priority for Perl. From that perspective, I see no reasons for Raku to "help Perl not to waste resources" (not that I wish Perl something bad).

@nxadm made a good point: if Perl 7 will appear, will that mean that Raku becomes even a lower priority?

@patrickbkr While I fully support the idea of a quick start with an MVP product, I would not agree with sending money to a black box :-) The TPF's donation process became better on the acquisition side, but it is still a black box for both observers and the sponsors.

[lizmat]

Lets create our own The Raku Foundation DBA (doing business as)

That is legally not an option, afaik. The DBA needs to be created by YAS.

[patrickbkr]

@ash I hope I'm not stirring up a hornets nest, but can't we do anything about the intransparency? Given we do most things independently and rely on YAS only for the money management aspect, then that sounds like a rather small problem to solve compared to what I suspect is a past full of experiences of difficulty of dealing with TPF. Do you think we can't even manage to sort that one topic out to both sides content?

@lizmat I don't have much of a legal background. Can you explain what the difficulties would be with YAS creating a DBA? (Actually I have no idea what a DBA actually is compared to, well, not having a DBA and still doing the money-y things via YAS).

[ash]

I’ve been waiting for two years after a personal promice that financial reports would appear. That did not happen.

I only got a request to approach sponsors to fund the conference and to leave the remaining money in the black box.

I do not believe this can be addressed.

[lizmat]

Can you explain what the difficulties would be with YAS creating a DBA?

There would be none. But it would have to be YAS to do that. In NL, this is as simple as telling the Chamber of Commerce the name you're also going to use as a "doing-business-as". This is a simple administrative action. Just as YAS has done with regards to "The Perl Foundation".

Lets create our own The Raku Foundation DBA (doing business as)

In interpreted that as: let's have people not associated with YAS create a DBA for YAS. That is legally not sound.

[patrickbkr]

@lizmat Understood. Thanks for clarifying!

[lizmat]

I only got a request to approach sponsors to fund the conference and to leave the remaining money in the black box.

FWIW, this is a long standing issue: I once donated 5000 US$ to TPF to help with the 5.10 release of Perl. I've yet to get even a thank you for that, let alone some kind of reporting. It does not help with the credibility of YAS.

I do not believe this can be addressed.

I'm not at this point YET. But getting closer to it, yes.

[nige123]

This is disappointing to hear. I'd like to thank you @lizmat. I've just passed on @ash's and your comment to the sponsorship committee at TPF. Hopefully we will hear from them soon.

[lizmat]

@nige123

Hopefully we will hear from them soon.

I was just mentioning it because of the pattern, not because I want to get recognition for something that happened like 13-14 years ago.

I favour a new DBA for the TPF that is not Perl-specific: "The Artistic Software Foundation" or even "Yet Another Society".

Just to be 100% clear: the real name of The Perl Foundation IS already YAS (aka Yet Another Society). "The Perl Foundation" IS already a doing-business-as of YAS.

[nige123]

Yes - understood (re DBA). To clarify what I meant there. I prefer "The Artistic Software Foundation" as a new doing-business-as name for Yet Another Society (YAS) - because it is language-agnostic and can easily support other community projects and events etc. A thriving computer language needs a thriving software ecosystem and the $whatever Foundation needs to support projects throughout their life cycle (e.g., inception, growth, maintenance, archive).

I hope Raku has multiple 'killer' apps in its ecosystem that attract users to start using Raku. Highly successful apps will need support for branding, community, events and sponsorship etc. It's more future-proof for the Foundation to have its own separate, project-friendly and language-agnostic identity. Community projects are actively encouraged and supported to grow their own distinctive branding identities and sub communities.

[lizmat]

I think it is a good idea to outline what the Raku community would like YAS to do:

1. register "The Raku Foundation" as a "doing-business-as" with whatever Chamber of Commerce-like entity YAS should do that.
2. register "therakufoundation.org" as a domain for YAS
3. set up DNS such that @rba can manage it

And the rest will be taken care of by the Raku community to produce a website with as little load on YAS as possible.

[lizmat]

@nige123:

"The Artistic Software Foundation"

I think a substantial part of both the Perl as well as the Raku community would like to, at least visually PR-wise, to be separated as much as possible. Having an "Artistic Software Foundation" fronting both Perl and Raku, would not satisfy that feeling. A feeling which I share, BTW.

[nige123]

I understand if you're just not feeling it.

Maybe we have a different view of the $foundation's role? My view is the $foundation should be in the background supporting, facilitating, helping etc.

Whatever the $foundation is it won't work if marketing and branding is outsourced to it. The project communities themselves need to create and build their own authentic brands - which means the communities themselves need to stand for, and stand by, their own brands - the $foundation will work best by helping the project communities to help themselves.

[ash]

I also feel this is strange. We do not need an abstract foundation that will start magically do all the work for us. They know nothing about the needs of Raku and I doubt they will understand them quickly. I would avoid converting Raku to an enterprise project.

[ash]

I think it is a good idea to outline what the Raku community would like YAS to do:

What they should do with funds and future grants?

[lizmat]

@ash

What they should do with funds and future grants?

Well, provide more clarity about the financial situation. But otoh, I don't think much would need to be changed on short notice wrt that? I mean, YAS has been funding jnthn and you for Raku related projects?

[muriloreis3]

I also feel this is strange. We do not need an abstract foundation that will start magically do all the work for us. They know nothing about the needs of Raku and I doubt they will understand them quickly. I would avoid converting Raku to an enterprise project.

My vision is that the foundation would be the entity that unifies our efforts, being part of the branding process, and what's your vision of a enterprise project? Because we are selling raku in a sense, not financially but in the sense of convincing others to adopt it

[ash]

what's your vision of a enterprise project?

By that I actually meant a bureaucratic management of the abstract foundation.

of convincing others to adopt it

I see this not as we have to ask "please use Raku" but in increasing visibility. Making a "Perl + Raku" FOSDEM track is not helping to achieve that goal as it could. Pushing a separate Raku track and/or devroom is what TRP should potentially do instead.

I think I made a mistake when I gave up preparing a Raku stand a couple of years ago and passed it to TPF, which converted it to a Perl+Raku stand.

[nige123]

I don't think it was a mistake. Perl programmers are the majority of new adopters (2020 survey):

[ash]

You can interpret it as “Raku is not visible enough outside of the Perl chamber”.

[codesections]

I think that this is drifting a bit off topic and that I'm contributing. But:

Perl programmers are the majority of new adopters (2020 survey)

I think this is a problem for both communities. IMO, Raku has a much better pitch to make to Ruby, JavaScript, and Python programmers than to Perl programmers – Raku and Perl are philosophically similar, but address significantly different use cases. Raku needs (again, imo) to grow by expanding its appeal well beyond Perl users.

At the same time, Perl needs Raku to not grow by converting Perl users to Raku. If the narrative is "the Raku community wants Perl users to switch to Raku", then our communities will necessarily be at odds, or at least have conflicting goals. But that's a false narrative; instead, we should both be focused on explaining the advantages of Perl-family languages to JavaScript developers, and growing both communities. Not only would this help keep us aligned, it's also just better strategy: both Perl and Raku offer clear advantages over JS (though in different use cases), so the argument is much easier to make. Plus, on a practical level, there are just a lot more JS devs – Raku can grow way more by convincing 5% of JS devs to try Raku than by convincing 5% of Perl devs to do so.

[StuartJMackintosh]

As things stand now, it is generally accepted by YAS (dba TPF) that the foundation is supporting Raku (language and community).

And, to further support Raku, TPF can work with the communities to:

1. increase engagement and inclusion with the Raku community, adding a YAS dba for Raku
2. help Raku establish itself independently
3. take no action

Noted the proposal from Liz above (https://github.com/Raku/problem-solving/issues/263#issuecomment-782015417) - it would be useful to find out if this is supported by the Raku community as it should be straight forward to implement (subject to domain availability etc).

We have our monthly community meeting this evening (where Raku community members are encouraged to join, and often do). We can make a space to open up this conversation with a view to working out the further conversations needed to progress this - do let me know if you want to come and join in or just observe.

I must request that all community members focus on the positive elements of their interests rather than negatively against others - this must not develop in to a counterproductive Raku vs Perl issue. I encourage you all to be positive, professional and respect every other human in our community.

Lets work actively and cooperatively, whether that means constructive separation, or commitment to develop YAS together.

[nxadm]

we should both be focused on explaining the advantages of Perl-family languages to JavaScript developers

At that moment the audience was lost.

(Clarification: my point is that Perl shouldn't have to care about Raku when (re-)positioning itself and the other way around. Also one of the advantages of the renaming was creating distance with the negative associations some people have regarding Perl. Doing "team" marketing undoes that.)

[jjn1056]

I think that this is drifting a bit off topic and that I'm contributing. But:

Perl programmers are the majority of new adopters (2020 survey)

I think this is a problem for both communities. IMO, Raku has a much better pitch to make to Ruby, JavaScript, and Python programmers than to Perl programmers – Raku and Perl are philosophically similar, but address significantly different use cases. Raku needs (again, imo) to grow by expanding its appeal well beyond Perl users.

At the same time, Perl needs Raku to not grow by converting Perl users to Raku. If the narrative is "the Raku community wants Perl users to switch to Raku", then our communities will necessarily be at odds, or at least have conflicting goals. But that's a false narrative; instead, we should both be focused on explaining the advantages of Perl-family languages to JavaScript developers, and growing both communities. Not only would this help keep us aligned, it's also just better strategy: both Perl and Raku offer clear advantages over JS (though in different use cases), so the argument is much easier to make. Plus, on a practical level, there are just a lot more JS devs – Raku can grow way more by convincing 5% of JS devs to try Raku than by convincing 5% of Perl devs to do so.

See this is the problem. I don't care about growing Raku at all. I think you are wrong that you're going to steal 5% or whatnot from Ruby and JS but honestly I don't care. What I care about is my Perl job. The job I have. Not some mythological Raku job that after 20 years of vanity hacking the Raku community has failed to create. Raku is a vanity project. Its a mistake. It's the biggest mistake Wall every made. You want to promote Raku? Fine go ahead, waste your time, its yours to do as you please. Just stop stealing time and resources from people with actual jobs.

[muriloreis3]

Then what are you doing here exactly? This is a Raku problem solving repository, in a topic about creating a Raku foundation

[niner]

On Freitag, 19. Februar 2021 14:30:39 CET John Napiorkowski wrote:

See this is the problem. I don't care about growing Raku at all. I think you are wrong that you're going to steal 5% or whatnot from Ruby and JS but honestly I don't care. What I care about is my Perl job. The job I have. Not some mythological Raku job that after 20 years of vanity hacking the Raku community has failed to create.

Actually, we're looking for a Raku programmer at Atikon. Experience with Perl is a bonus as we also have a large Perl code base.

[rfilipo]

I believe both Perl and Raku need a background Foundation. I believe, nevertheless, Perl and Raku need to have independence and deserve this own Foundation. I defend the Raku Foundation for Raku Language and the Perl Foundation for the Perl Language.

Perl and Raku are actually two different languages, different projects with different infrastructure, necessities, and facing opposite situations. Obviously, both languages will not survive under the same strategic plan. As Perl is a mature, universally used language, needing maintenance and adaptation to the evolving IT scene, Raku is a new, promising modern language, needing much more attention to library creation, experimental projects, heading to new paradigms, and methodologies.

As a new product, Raku also still needs some evangelization, educational actions, and marketing campaigns to acquire the needed reputation to thrive. In a few words, the Raku community is still growing. The language is still under heavy development and needs a really big effort to be a mature tool.

Perl, on the opposite side, is a mature, well-known language, well-tested language, used as a system program language in several Unix and Linux distributions.

I believe bringing separated governance and founding will help both. Perl shall renovate its importance and cult presence in the IT and UNIX-like scene and Raku will find the path to its exotic calling, to be a post-modern language with singular and clever style.

[jjn1056]

As things stand now, it is generally accepted by YAS (dba TPF) that the foundation is supporting Raku (language and community).

And, to further support Raku, TPF can work with the communities to:

1. increase engagement and inclusion with the Raku community, adding a YAS dba for Raku
2. help Raku establish itself independently
3. take no action

Noted the proposal from Liz above (#263 (comment)) - it would be useful to find out if this is supported by the Raku community as it should be straight forward to implement (subject to domain availability etc).

We have our monthly community meeting this evening (where Raku community members are encouraged to join, and often do). We can make a space to open up this conversation with a view to working out the further conversations needed to progress this - do let me know if you want to come and join in or just observe.

I must request that all community members focus on the positive elements of their interests rather than negatively against others - this must not develop in to a counterproductive Raku vs Perl issue. I encourage you all to be positive, professional and respect every other human in our community.

Lets work actively and cooperatively, whether that means constructive separation, or commitment to develop YAS together.

Any chance you could publish some details about where this monthly meeting happens?

[StuartJMackintosh]

Yes - the details are here: https://codimd.opusvl.com/KgPB3Jj4QOiCPdFL5EsTVA?view#

[jjn1056]

I must request that all community members focus on the positive elements of their interests rather than negatively against others - this must not develop in to a counterproductive Raku vs Perl issue. I encourage you all to be positive, professional and respect every other human in our community.

I hope you can understand that it's not easy for this not to become a Perl versus Raku issue for many of us. As a working Perl professional who has no interest in Raku (not that there's Raku jobs flooding the market) it really feels to me like Raku is just a distraction at best and a serious drain on time and resources at worst. That's just how I and many of us feel based on the last 20 years of Perl decline. I would have less problem with Raku if it seemed like there was a real plan to address Perl fortunes I guess. But given the lack of resources I would simple prefer to focus on the many thousands+ of Perl programmers worldwide. Perl isn't a game for us, it's how we put food on the table. I don't see TPF being serious about any of this. And we waste a lot of time and energy fighting.

[ash]

If the RSC already decided that "the Raku community is asking YAS to make a DBA" then I believe I have nothing more to say.

[lizmat]

I think we have this discussion to find out what the Raku community wants, so I reopened this issue. @jjn1056's comments I know reflect the opinion of a large part of the vocal, and not so vocal Perl community. It is precisely for these types of feelings, which I know do exist with some of the TPF board members to some extent, that I have refused to entertain the thought of becoming a board member of TPF, because that would just lead to long, fruitless discussions.

In any case, @jjn1056's comments have made it clear to me that even if YAS would like to do a DBA for The Raku Foundation, that this would still be a problem for a large part of the Perl community. And that it would be detrimental to the trust that The Perl Foundation should get from the Perl community.

So I'm starting to further lean into needing to start a completely separate Raku Foundation. If not for Raku to be able to spread its wings, then for Perl to find its future without any actual or perceived trust issues from its community.

We will discuss this in an RSC meeting soon.