-
Notifications
You must be signed in to change notification settings - Fork 16
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
Comments
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. |
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. |
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 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. |
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. |
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. |
That, in a nutshell, describes the conundrum. :-) |
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. |
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. |
@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. |
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. |
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 |
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. |
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.) |
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 |
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. |
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] |
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. |
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 perceptionTo 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 decisionsI 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. |
@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. |
That is legally not an option, afaik. The DBA needs to be created by YAS. |
@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). |
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.
|
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".
In interpreted that as: let's have people not associated with YAS create a DBA for YAS. That is legally not sound. |
@lizmat Understood. Thanks for clarifying! |
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'm not at this point YET. But getting closer to it, yes. |
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.
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. |
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. |
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. |
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:
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.
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 @dduncand wrote:
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.
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.
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! |
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 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. |
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.
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. |
These quasi-historical metaphors do this conversation no good at all. Let's not. |
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. |
@jnthn I wish Github had a broken heart emoji. Keep up the good work! |
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. |
In a comment above, @lizmat mentioned |
Solution for #263, formal request for The Raku Foundation
Probably that guy: https://github.com/flokosiol |
Why do you say so? |
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. |
Why not foundation.raku.org? |
We already have raku.foundation secured.
|
Great. Thanks. |
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 |
Which makes it almost 100% guaranteed that this is unfriendly acquisition and we must leave the domain alone. |
Can we just go with raku.foundation instead and simply ignore |
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:
#263 (comment)
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/
|
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 I haven't looked into this in detail, but I would argue that we've already taken the risks attendant with the 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 In particular, might More generally, will corporations and individuals really trust the At the moment I can't escape the sense that I'd be delighted to see solid evidence my fears are unfounded, but I do urge caution. |
@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. |
The Raku Foundation exists, so this closes #263
TL;DR
We have to establish the Raku Foundation (TRF).
What
The most obvious things TRF is responsible for:
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.
The text was updated successfully, but these errors were encountered: