Problem-solving: 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.

[sigzero]

I would be in favor of a complete split.

[codesections]

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.

I believe this was a reference to my comments in the recent community meeting. If so, I agree with @lizmat's reopening of the issue; as this discussion has made clear, there is more to say. What I intended to communicate in the meeting – and my apologizes if I didn't make this clear – was that, in our meeting a few weeks ago, the RSC decided that asking for an official DBA would be a good first step. I don't believe there was any discussion of whether or not that would be the only step and, in any event, that conversation obviously took place before the discussion in this issue thread (indeed, before this issue was opened). This is clearly a conversation worth continuing.

[CountZero1959]

I was not a fan of renaming Perl6 to Raku, but the community has decided to go ahead, and it is no use crying over spilt milk. Now that Raku has its own namespace separate from Perl, one should go all the way and give it its own organisation.

But that will create some logistical problems (if I understand some of the previous comments correctly). Therefore, I suggest that TPF would morph into a meta-organisation that, in its turn, spawns two equal subordinate organisations: Perl5/7 and Raku.

So the top-level would be YAS (the old TPF). TPF (newly founded, but getting all the history, traditions and assets of the old TPF as far as they pertain to Perl) and TRF (newly founded and getting a fresh start) would be separate organisations. YAS would serve them both. YAS would be "language agnostic" and have the singular purpose to support both TPF and TRF. YAS would not meddle with the internals of TPF and TRF. Each of these would self-organize and not exist as a DBA of YAS.

In that respect, may I suggest one looks into the Belgian "Internationale Vereniging" (or "International Association"), a legal entity that seems perfect for this kind of organisations? It has full transparency and is controlled by a General Assembly of voting members, and is led by a Board of Directors. It is simple to set-up. It is a legal entity in its own right. Its liabilities do not extend to its members. With the New Code of Companies and Associations in Belgian law, it is now quite modern and streamlined.

This structure would allow YAS to become a member of each association. That will give YAS a legal right to look into TPF and TRF's workings but not control it as it will have only 1 vote, and there would be many more members in each association.

I think such a structure would allow a clear separation of concerns between YAS and TPF/TRF. For instance, the organisation of a YAPC or YARC could still be done on the YAS level. YAS would take care of the logistics and such, and TPF/ TRF would arrange the content and local support. It would show the world the common ancestry of both languages and allow each language to forge its own path.

And we make Larry Wall an honorary member of both TPF and TRF.

[duncand]

EDIT: This comment is superseded, please see my subsequent one.

We want to be practical if we're going to move forward. A key part of this is changing things incrementally as we have the actual means to do so.

In the short term, YAS creating a Raku Foundation DBA would take very little effort or seriously increase the workload while having immediate solid benefits that the public can see, which is that "The Perl Foundation" and "The Raku Foundation" exist separately with their own websites and branding and projects and so on.

Having actual completely separate foundations can come later when the resources actually exist to run them.

One would have to assume by default that separate foundations would mean up to twice as many people are required to run them in contrast to with a common foundation, although its likely to be less.

For those of you who believe having fully separate foundations and not just two DBAs is the ONLY way forward, AND you do not currently work for YAS, I invite you to publicly offer that you are stepping up as a candidate, and in what specific role(s), to be one of the additional needed people who will put your time into running one of the separate foundations in addition to whatever you are doing now.

If you're not going to step up, then you haven't made a compelling enough case that actual separate foundations are even possible, and then you should accept having DBAs as a reasonable short term solution.

[duncand]

To clarify my prior comment, I was assuming the common practice in business that the act of creating a new foundation includes naming those who would run it, so that it was actually physically able to function out of the gate. However, I realize it is also possible for YAS to declare yes we are definitely creating the separate foundation and register it, prior to it being determined who would run it, and the new leaders could sign up to do so after the fact. I retract what I said before that we need to figure out a leadership slate prior to creating the additional foundation. So there's nothing really stopping us from creating the new foundation right away and then figuring out other details of who will run it after the fact.

[8-64]

That was certainly an interesting discussion to read!

Making a separate Raku Foundation makes sense - initially it was supposed to be a Perl 6, but after renaming and branching out it became a separate but sister language. Now with anticipation of Perl 7 being released at some future point I see some possible conflict of interest there - like trying to promote "refreshed old Perl 5 as Perl 7" vs "previous version of Perl in disguise" by the same organization. Maybe it will help with marketing and promotion of both languages by helping to focus only on one language and its ecosystem? And points about visibility and accountability are true as well.

Another point is to promote not only the language and frameworks but the whole ecosystem. What are some popular widely-used products written in Perl or Raku and using it? I have trouble naming many. Maybe having a separate organization per language will help to gather some products, organize their communities and relentlessly promote them even if they have some drawbacks. Ruby also has suffered a significant decline (or at least public perception of decline) in popularity, but it's still going strong because things like Chef, Puppet, or fluentd are towing it and keeping it used. I want to see at least the same with Perl and Raku.

[autarch]

As @StuartJMackintosh has already stated, if the Raku community wants its own legally separate foundation, then TPF will support you in that effort.

However, I wanted to address some statements in these comments about the _technicalities_ of this sort of thing. Keep in mind that I only know how this works in the US. Given that Raku seems to have more Europeans as a percentage of those involved than Perl, a separate TRF might prefer to incorporate somewhere in Europe.

@CountZero1959 wrote:

So the top-level would be YAS (the old TPF). TPF (newly founded, but getting all the history, traditions and assets of the old TPF as far as they pertain to Perl) and TRF (newly founded and getting a fresh start) would be separate organisations. YAS would serve them both. YAS would be "language agnostic" and have the singular purpose to support both TPF and TRF. YAS would not meddle with the internals of TPF and TRF. Each of these would self-organize and not exist as a DBA of YAS.

In that respect, may I suggest one looks into the Belgian "Internationale Vereniging" (or "International Association"), a legal entity that seems perfect for this kind of organisations? ...

Yet Another Society is a US non-profit corporation (registered in Michigan, for reference). The US structure I know of that's closest to what is proposed above is a fiscal sponsorship arrangement. This allows an existing non-profit to extend their legal and tax-exempt status to other groups without those other groups having to incorporate, apply for 501c3 status with the IRS, etc.

This is definitely way simpler for the sponsored group (TRF and TPF both, as described), as the sponsor has the most legal obligations. However, I believe it can be a fair bit more complicated for the sponsoring org (YAS), though this probably depends on how much autonomy the sponsored groups have. But if they each have their own boards, budget, and so on, I think this might be a fair bit of extra work for YAS. So if this is a direction we want to go, we would need to do a fair bit of research on how best to do this. The Software Freedom Conservancy basically exists to be a fiscal sponsor for groups formed around free software projects, so talking to them about how that works would be a good first step.

Maybe there are other structures in the US similar to the Belgian one described above, but I don't know what they are.

This structure would allow YAS to become a member of each association. That will give YAS a legal right to look into TPF and TRF's workings but not control it as it will have only 1 vote, and there would be many more members in each association.

YAS is not currently a membership organization. A formal membership nonprofit in the US is a different legal structure from what we currently have. Becoming one would require us to write, file, and abide by entirely new bylaws. Those bylaws would require us to have a defined membership that votes in the board, probably from day one of the new filing. Note that this is different from an informal "membership", which a lot of nonprofits use as a fundraising approach ("join $local_public_radio today as a member for just $10/month and we'll send you this great mug").

@dduncand wrote:

In the short term, YAS creating a Raku Foundation DBA would take very little effort or seriously increase the workload while having immediate solid benefits that the public can see, which is that "The Perl Foundation" and "The Raku Foundation" exist separately with their own websites and branding and projects and so on.

Yes, this is true! Filing a DBA will cost us $10 or $25 (I can't remember which) and requires filing one form with the state of Michigan. It also requires us to update our banking info so that the bank accepts checks made out to "The Raku Foundation". I don't think there's much more work required than that.

One would have to assume by default that separate foundations would mean up to twice as many people are required to run them in contrast to with a common foundation, although its likely to be less.

Keep in mind that TPF has a lot more volunteers than just the board, including the grants committee, conference organizers, volunteers working on infrastructure projects, the website, fundraising, etc.

How many people a separate TRF would require really comes down to how much work each person involved wants to do. You could have just a board of three people who do all the stuff, but that sounds like a recipe for burnout.

I was assuming the common practice in business that the act of creating a new foundation includes naming those who would run it, so that it was actually physically able to function out of the gate. However, I realize it is also possible for YAS to declare yes we are definitely creating the separate foundation and register it, prior to it being determined who would run it, and the new leaders could sign up to do so after the fact.

This isn't technically correct. The initial incorporation, at least in the US, typically requires you to name an initial board of at least 3 people, a President, Secretary, and Treasurer. The exact requirements vary by state. Of course, nothing requires that board to continue being the board for any length of time. The board could vote to entirely replace itself the day after incorporation. But you do have to have some names on that initial filing documentation. Of course, if you can find people to replace them with, they might as well be the initial board anyway!

[lancew]

I grudgingly support this proposal.

It's clear that the Raku core want out, the rename was step one; this is step two.

It feels very BREXIT-y to me.
I don't know the numbers of Perl to Raku developers, sponsors, etc. But I can assume in this metaphor Raku is the UK, and Perl/TPF the EU.

I do think it will make things clearer. Perl Weekly can stop having Raku in there. Raku weekly could stop having Perl in there. Everyone can stop appending "...and Raku (formerly Perl6)" to things. And Raku will no longer have to mention Perl other than on history and origin pages.

Both communities can focus on their community, both foundations can serve their community. Both have different needs so that makes sense.

It frees both communities from a tangled past and stops the increasing oddity of Perl (and the TPF) supporting another language/community that does not want to be part of Perl.

Individuals can be members of both.

[lizmat]

@lancew

that does not want to be part of Perl

Sorry, but this is not how it went. Do you REALLY think I suggested the name change after for at least SEVEN years trying to get to a joint future? At significant emotional and financial investment? REALLY?? Just read @jjn1056's responses in this issue, and you'll understand why I suggested the name change.

It frees both communities from a tangled past and stops the increasing oddity of Perl (and the TPF) supporting another language/community

Indeed it does. But please, this is NOT just because the Raku community wants this. If you want metaphors, Perl is the UK, and Raku is the US in 1776.

[jjatria]

These quasi-historical metaphors do this conversation no good at all. Let's not.

[jnthn]

It's clear that the Raku core want out, the rename was step one; this is step two.

I imagine I count as core, and for me it's never been "want out". I've made no small amount of effort - in public and in private - in support of the principle that one community can grow and evolve two languages, each of which have their various strengths and weaknesses. Thus in principle, on an issue like this, I'd be here arguing that duplication of effort in running a foundation is a loss for all of us, and thus endorse the DBA route, along with encouraging folks whose primary interest is in Raku to do their share of the foundation work.

Alas, I find myself becoming a bit weary to keep arguing for such things. I've been glad of a great deal of support for my work on Rakudo, MoarVM, and other related projects - both morally from numerous individuals in the community, and financially from TPF. At the same time, 12 years of hearing vaporware this and vanity project that have a cost. It's like the sea gradually eroding a cliff; it all happens very slowly, but some day, the result becomes noticeable. I don't "want out", and you won't find me arguing for it. But I suspect I'm not alone in finding my strength to argue against it slowly crumbling.

[nxadm]

@jnthn I wish Github had a broken heart emoji. Keep up the good work!

[codesections]

People have made some excellent and constructive points in this thread; I now have a lot more to think about, and I'm sure that the same is true for many other members of the Raku community. I believe, however, that we've now discussed pretty much all sides of the issue and that additional discussion is more likely to create conflict than to introduce a new perspective.

For that reason, I am at least temporarily locking conversation on this issue. Please let me know via email or IRC if you believe that opening this thread back up would promote productive conversation.

[vrurg]

In a comment above, @lizmat mentioned therakufoundation.org domain. The very same day somebody has registered this and .com versions of the name. I hope it was a protective reservation. May I ask the owner to share his opninion with us?