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.

[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?

[demostanis]

Probably that guy: https://github.com/flokosiol

[JJ]

Why do you say so?

[patrickbkr]

The domain now has a gitlab installed referencing the 3st company. Here is their contact info. Florian Kosiol seems to work for them. I'll get in contact.

[nxadm]

Why not foundation.raku.org?

[JJ]

We already have raku.foundation secured.

[JJ]

The domain now has a gitlab installed referencing the 3st company. Here is their contact info. Florian Kosiol seems to work for them. I'll get in contact.

Great. Thanks.

[patrickbkr]

I got a very kind reply back from 3st. 3st did not register that domain, were not aware of the registration and can not explain why the domain is linked to one of their servers. Something else must have happened. It's still a mystery. Whois shows very little information. If I read it correctly the only information the registrant provided is that they are located in Arizona.

Edit: The domain is registered by Domains by Proxy, a company specialized in concealing the real owners of a domain. I guess the buyer of therakufoundation.org wants to stay anonymous.

[vrurg]

The domain is registered by Domains by Proxy, a company specialized in concealing the real owners of a domain. I guess the buyer of therakufoundation.org wants to stay anonymous.

Which makes it almost 100% guaranteed that this is unfriendly acquisition and we must leave the domain alone.

[patrickbkr]

Can we just go with raku.foundation instead and simply ignore / [ the ]? rakufoundation\. [ org | com ] /? (Actually I like raku.foundation a lot.)

[Tyil]

On Tue, Mar 30, 2021 at 08:19:06AM -0700, Patrick Böker wrote:

Can we just go with raku.foundation instead and simply ignore / [ the ]? rakufoundation\. [ org | com ] /? (Actually I like raku.foundation a lot.)

-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/Raku/problem-solving/issues/263#issuecomment-810348276

I think we should just go with raku.foundation too. It's a "modern" TLD, which I think fits perfectly with a modern organisation working on a modern language.

-- With kind regards,

Patrick Spek

www: https://www.tyil.nl/ mail: @.*** pgp: 1660 F6A2 DFA7 5347 322A 4DC0 7A6A C285 E2D9 8827

git: https://git.tyil.nl/

[raiph]

I think we should just go with raku.foundation too. It's a "modern" TLD, which I think fits perfectly with a modern organisation working on a modern language.

It does sound perfect. But have you considered the potentially catastrophic risks attendant with choosing it?

More generally, what are the pros and cons of foundation.raku.org vs raku.foundation?

I haven't looked into this in detail, but I would argue that we've already taken the risks attendant with the .org tld and we should carefully consider any notion of taking on the risks attendant with adopting the .foundation tld in addition.

My own take is that I don't trust registrars in general and I don't trust ICANN either. But they're what we've got, so our best option imo is to pick the least risky. I don't know why ICANN recently cancelled the sale of .org by the supposedly non-profit Public Interest Registry to what seems to be a for-profit entity, but for now at least .org seems in another league trustworthiness wise compared to the essentially unmoderated .foundation and its owner (John Dale, LLC, doing business as "Donuts").

In particular, might raku.foundation ever be seen as a valuable target? How confident can we be that it won't be seen as valuable, and/or that, if it is and is hijacked, we'll not only be able to respond as well as Perl folk did in their loss of perl.com, but won't suffer relatively catastrophic reputational damage even if we get it back as quickly as the Perl folk got perl.com back?

More generally, will corporations and individuals really trust the .foundation tld, and foundations that use that tld? Are reputable foundations using it en masse? Even if so, is there any significant level of scepticism among more reputable foundations about the .foundation tld?

At the moment I can't escape the sense that foundation.raku.org might be both a much more compelling URL for a trustworthy foundation than raku.foundation and a better choice from a financial, administrative, and technical perspective too.

I'd be delighted to see solid evidence my fears are unfounded, but I do urge caution.

[lizmat]

@raiph: All good points. Oddly enough, https://perl.foundation is actually also a thing, redirecting to perlfoundation.org. There's nothing stopping us from doing something similar, redirecting to https://foundation.raku.org. Should we feel that way.

In any case, I've registered the raku.foundation domain, and it has the transfer lock active. Whatever security that brings.