Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The Raku Foundation #263

Closed
ash opened this issue Feb 16, 2021 · 76 comments · Fixed by #300
Closed

The Raku Foundation #263

ash opened this issue Feb 16, 2021 · 76 comments · Fixed by #300
Assignees
Labels
fallback If no other label fits

Comments

@ash
Copy link

ash commented Feb 16, 2021

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.

@ash ash added the fallback If no other label fits label Feb 16, 2021
@duncand
Copy link

duncand commented Feb 17, 2021

@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
Copy link

Leont commented Feb 17, 2021

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
Copy link
Collaborator

lizmat commented Feb 17, 2021

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
Copy link

duncand commented Feb 18, 2021

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
Copy link
Contributor

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
Copy link
Collaborator

lizmat commented Feb 18, 2021

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

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

@nige123
Copy link

nige123 commented Feb 18, 2021

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
Copy link

jjn1056 commented Feb 18, 2021

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
Copy link

nige123 commented Feb 18, 2021

@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
Copy link

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
Copy link

nxadm commented Feb 18, 2021

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
Copy link

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
Copy link
Contributor

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
Copy link

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
Copy link
Contributor

vrurg commented Feb 18, 2021

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
Copy link

djzort commented Feb 19, 2021

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
Copy link

akuks commented Feb 19, 2021

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
Copy link
Member

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
Copy link
Author

ash commented Feb 19, 2021

@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
Copy link
Collaborator

lizmat commented Feb 19, 2021

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
Copy link
Member

patrickbkr commented Feb 19, 2021

@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
Copy link
Author

ash commented Feb 19, 2021 via email

@lizmat
Copy link
Collaborator

lizmat commented Feb 19, 2021

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
Copy link
Member

@lizmat Understood. Thanks for clarifying!

@lizmat
Copy link
Collaborator

lizmat commented Feb 19, 2021

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
Copy link

nige123 commented Feb 19, 2021

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
Copy link
Collaborator

lizmat commented Feb 19, 2021

@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
Copy link

nige123 commented Feb 19, 2021

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.

image

@8-64
Copy link

8-64 commented Feb 20, 2021

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
Copy link

autarch commented Feb 21, 2021

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
Copy link

lancew commented Feb 22, 2021

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
Copy link
Collaborator

lizmat commented Feb 22, 2021

@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
Copy link

jjatria commented Feb 22, 2021

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

@jnthn
Copy link
Contributor

jnthn commented Feb 22, 2021

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
Copy link

nxadm commented Feb 22, 2021

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

@codesections
Copy link
Contributor

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.

@Raku Raku locked and limited conversation to collaborators Feb 22, 2021
@Raku Raku unlocked this conversation Feb 25, 2021
@vrurg
Copy link
Contributor

vrurg commented Feb 25, 2021

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?

lizmat added a commit that referenced this issue Mar 19, 2021
Solution for #263, formal request for The Raku Foundation
@demostanis
Copy link

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

@JJ
Copy link
Contributor

JJ commented Mar 30, 2021

Why do you say so?

@patrickbkr
Copy link
Member

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
Copy link

nxadm commented Mar 30, 2021

Why not foundation.raku.org?

@JJ
Copy link
Contributor

JJ commented Mar 30, 2021 via email

@JJ
Copy link
Contributor

JJ commented Mar 30, 2021

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
Copy link
Member

patrickbkr commented Mar 30, 2021

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
Copy link
Contributor

vrurg commented Mar 30, 2021

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
Copy link
Member

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

@Tyil
Copy link
Member

Tyil commented Mar 31, 2021 via email

@raiph
Copy link

raiph commented Mar 31, 2021

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
Copy link
Collaborator

lizmat commented Mar 31, 2021

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

JJ added a commit that referenced this issue Oct 2, 2021
The Raku Foundation exists, so this closes #263
lizmat pushed a commit that referenced this issue Feb 20, 2022
* Communicating the effective establishment

The Raku Foundation exists, so this closes #263

* Addressing @vrurg comments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
fallback If no other label fits
Projects
None yet
Development

Successfully merging a pull request may close this issue.