Marketing, Public relations, Branding #395
Replies: 17 comments 43 replies
-
|
I would like to see some articles of various types "approved" by the RSC and general community so that we can offer them in likely places. For example, I am working on an article to be submitted to CodeProject.com intoducing Raku to mainly Windows-using Python and C++ programmers. I have my article on github and will ask for fellow Rakuuns to critique it when it's far enough along. Another thing which would be helpful is to somehow get the old Perl 6 marketing materials converted to read "Raku." Perhaps David Warring, our PDF expert can do that. I'll ask him now. |
Beta Was this translation helpful? Give feedback.
-
|
Just one thought. |
Beta Was this translation helpful? Give feedback.
-
|
@frithnanth As I said some languages have had systematic corporate support. Raku has moved forwards without - evidence of its fundamental strength. |
Beta Was this translation helpful? Give feedback.
-
|
@finanalyst I didn't mean for the rakoons to shop for corporate support, I was just describing a path that had been taken by others. |
Beta Was this translation helpful? Give feedback.
-
Imo, this lack of corporate backing is both evidence of Raku's strength and one of the sources of that strength. For-profit companies don't donate money or developer time to programming languages out of the goodness of their corporate hearts; they donate because doing so makes the programming language better for their use case. Sometimes, of course, this means fixing bugs or implementing already-designed features in a way that makes the language better for everyone. But, because nearly everything in language design involves tradeoffs, its easy for this support to result in adding features that are good for a business use case – even if they crowd out/are incompatible with features that are better for smaller teams or foss developers. (My 2021 FOSDEM talk, Imagining the Ideal Language for Writing Free Software went into this in much more detail. But the bottom line is that, in a world where Raku had received significant big-tech backing, I really doubt we'd have gotten a language nearly as powerful (for non-big-tech use cases) as the Raku we have today.) |
Beta Was this translation helpful? Give feedback.
-
|
As a mostly volunteer effort it's even more important that Raku's marketing is as efficient/focused as possible. Compared to big, well funded corporate marketing efforts we have fewer marketing arrows to fire, less people to fire them resulting in limited targets to hit. This is not a bad thing. Constraints can work to our favour provided we recognise them and plan accordingly. The first constraint is limiting Raku's brand values. Let's have just three and pick the most distinctive and Raku-ish. The core three values need to be formally adopted by the RSC and will permeate the marketing messages the community use to reach its first target audience (e.g., solopreneurs, AI researchers, CS200 university lecturers, *)).pick(). Whatever audience the RSC chooses (initially just one) the community needs to create Raku powered projects this audience will adopt. Promoting just the language in a crowded market is not enough - early adopters need Raku-powered solutions to their problems (e.g., toolkits, game engines, frameworks etc). We shouldn't try and be everything to all people. Perl's marketing suffered from this (e.g., swiss army chainsaw memes etc) all while not owning its branding (e.g., "perl" and camel). At least Raku has legal ownership of its trademarks - it's now time to use them. Some suggested next steps are:
|
Beta Was this translation helpful? Give feedback.
-
|
I would globally The Raku community is self-governing and operates through community consensus. The RSC plays a role in that process, of course – often a vital one, especially when discussions have stalled or reached a logjam. And I expect that the RSC will play a role in formalizing the community's consensus in some way, partly so we can treat certain questions as "settled for the medium term" and move on to other issues. But the Raku community as a whole – not the RSC – must determine things like "Raku's top values". |
Beta Was this translation helpful? Give feedback.
-
|
@nige123 tl;dr I agree with three of your suggestions, I'm pushing back on one Limiting to three brand values - push backThis idea, variations of which I have heard elsewhere, seems to me to be a fashionable consultant-type suggestion. All sorts of marketing types say things like 'focus on the mission statement' as if it is an infallible solution. Yet there is some hidden truth to the idea of three brand values. The rule of three is an oratorical device that is evidenced in literature almost since written language started (the Gilgamesh Epic from 2500 BCE has a flood story that the Bible repeated, in which a bird is sent out three times). Once is an event, twice is a coincidence, thrice is a series, four times (note there is no English word for four times) is also a series so adding another element to the list adds no more meta information. We also seem to remember groups of three more easily. So having a group of three items can make something easy to remember, and choosing the group in a clever way helps to fix the memory (eg. Churchill's 'never in human history have so many [1] owed so much [2] to so few [3]' is a group of three that is not a list, but it is a powerful phrase because there are three linked components). The suggestion was to choose 'brand values', but what then is a brand value? Raku has very many strengths and values so limiting our focus to three is difficult because different people are going to order the various values in different ways, so we can easily get distracted about which to choose. In addition, different strengths will appeal to different audiences. I can agree that we should try to market to narrower audiences, and so choosing brand values for that audience would be appropriate. But would other audiences be put off? Suppose we interpret the term 'brand value' more generally and talk about the messages that we wish to convey about Raku. Given the size of the language, and its intellectual depth, it might be possible to distill the project into three, but they would be so abstract as to be unintelligible. What for example would an ordinary person think about a 'thunk', a 'blorst', or for the upcoming release an 'abstract symbol tree'? To get a good description of Raku requires abstract sentences, but they are not useful for marketing. However, creating descriptions of Raku using a rule of three does make for good marketing. Memorable descriptions help people recall Raku even after the rest of the advert / blog / article has been forgotten. Rather than having one set of messages or brand values, perhaps, we could also have several group-of-three descriptions highlighting different aspects of Raku, and then have a campaign in which each quarter we ask the Raku community to write a blog, article, etc that uses one of the descriptions. Here are some strengths I find in Raku [what do you think are strengths?]:
There are other things I think are important:
|
Beta Was this translation helpful? Give feedback.
-
|
Glad you agree with three of the suggestions:
In regard to choosing just three brand values, the reason is for cognitive efficiency to help enable brand virality (contagiousness). The rule of three in oratory is another manifestation of this. It's a simpler, more powerful pill for the audience to swallow. Sorry if you have seen this before but here is an explanation of brand values in an 'Authentic Brand Stack' for Perl and Raku. |
Beta Was this translation helpful? Give feedback.
-
|
Large language models offer an interesting way of uncovering branding associations/values. Here is what ChatGPT 3.5 currently reckons in answer to, "what are three distinctive brand values for the Raku programming language?"
|
Beta Was this translation helpful? Give feedback.
-
|
@finanalyst there is quite a bit of overlap here with your values list (e.g., community esprit de corps , developer-friendly features etc). Quite a lot of that rings true to me too. I don't want to be dogmatic here about "three values only" and the reality is these values will naturally morph over time - the important thing is we have some to start informing the marketing messages sent to the initial, early adopting audience. |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
@nige123 Just watched your talk from 2 years ago. I hadn't seen it before. |
Beta Was this translation helpful? Give feedback.
-
|
Again, I'd |
Beta Was this translation helpful? Give feedback.
-
|
@nige123 @frithnanth This discussion is to work through ideas, and to develop consensus in the Community. By consulting together opening and freely, the whole community can become aware of why the RSC or Raku & Perl Foundation eventually (will) take various decisions. @frithnanth I would push back on your statement that 'any language is easy to read to those fluent in it'. Some of Raku's expressiveness and tolerance is not matched by other languages. For instance, In addition, Raku is easier for people who are not fluent in it. I do not understand your comment about 'write-only-language trolls'. Or why Perl6 matters. We are not trying to hide that Raku used to be called Perl6. If you are saying that there will be people who will fling criticism at Raku for the flaws in Perl, they will do that any way. |
Beta Was this translation helpful? Give feedback.
-
|
I think the most important sentence so far is "Whatever audience the RSC chooses (initially just one) the community needs to create Raku powered projects this audience will adopt." |
Beta Was this translation helpful? Give feedback.
-
I think this is another good-but-dangerous idea. Yes, projects attract users. But chasing a "killer app" can be a dangerous gamble with no guarantee of any payoff. Plus, developing a cool project that gains widespread adoption is already the sort of thing that many programmers aspire to; I'm not sure that we need to add extra emphasis to that goal. Instead, I'd like to see the community focus at least as much on removing the paper cuts (missing tooling, outdated docs, abandoned libraries) that add friction for developers adopting a new language. And, as more devs code in Raku, I am pretty sure they'll build ambitious projects of the sort you mentioned. But, just so I'm not too much of a hypocrite, I'll mention that much of my free time is currently going to an application that, in my dreams, attracts people to Raku in the way you describe. |
Beta Was this translation helpful? Give feedback.
-
|
My long term vision for Raku includes it to have excellent Just imagine: Write your program in Raku and without any difficulty or complex setup use the Java POI libraries to interface with MS Office files, then you pull in Pygments from the Python world and then you are still able to pull in your favorites from the CPAN and have NativeCall available to interface to all of the C world. All in the same project. |
Beta Was this translation helpful? Give feedback.
-
|
Using @finanalyst's Having-good- |
Beta Was this translation helpful? Give feedback.
-
|
O this was where CPAN was mentioned. Searching CPAN for a module to do X, when X is not a common task is daunting. Doing so with the qualification of "in Raku lang" is not something I would suggest to a newcomer since there is no easy way to search by implementation language (as of about a year ago). |
Beta Was this translation helpful? Give feedback.
-
|
(This is slightly tangential, but at least for my use cases |
Beta Was this translation helpful? Give feedback.
-
|
OOC, would you want to have a parser that parses Javascript to RakuAST? Or really inline an existing Javascript engine. The former appears to be more portable and maybe useful to me, albeit with probably less performance? |
Beta Was this translation helpful? Give feedback.
-
I hadn't really considered the first option. The main thing I was thinking about was JS interop/package availability. For that to work (reliably), a parser would need to be able to translate 100% of JSs semantics to Raku, which seems like an ambitious goal, but maybe I'm misunderstanding. Re: portability, I'm not sure; Node is super widely available, and Deno is installable as a static binary. (If you'd like to discuss this further, lets move it out of this discussion to avoid further crowding an already-crowed space) |
Beta Was this translation helpful? Give feedback.
-
|
Target audience? We should look at ourselves and also how and why we came to Raku. Those of us who are not the primary designers or builders of Raku and its implementations, are the group to which Raku has been successfully marketed. Especially those who did not get here by way of Perl show us our markets. Edited: The |
Beta Was this translation helpful? Give feedback.
-
|
@raiph's is good point regarding my corrected but still overstated "has been played out". There must be nuggets there and gaining just one person of quality is significant. To me that seems more like building the community than marketing Raku. And that is a foggy distinction which I feel is significant. @raiph, I think we 100% agree on that point. To restate: Raku has had some success gaining users; understanding that success may inform future efforts to expand usage. So using the marketing approach, my guess is that the Perlers are a sympathetic but small group which is relatively well informed about Raku. Most are probably part of a larger group to which we might market. @raiph, thanks again for pointing out fault in my grammar or expression. I believe common usage is that show and shows are both present tense; and shows only pairs with the third person singular subject. I appreciate your purely present tense as a suspenseful hook clarified in a timely manner. More for this discussion later. |
Beta Was this translation helpful? Give feedback.
-
I think this is a good – but potentially dangerous – idea. Yes, we should look at how we came to Raku and think about how Raku could attract users in similar ways. But we should be careful not to go too far in that direction – it's easy (natural, in fact) to think from our own perspective and to believe that a message that would appeal to us would appeal to others. But we want Raku to be appealing to users who aren't like us along a huge number of axes. And, after all, we seem to agree that Raku hasn't always presented itself as well as it could – so we should also give thought to who might have joined the Raku community if our messaging had been a bit better. |
Beta Was this translation helpful? Give feedback.
-
|
I think what @codesections said really shouldn't be overlooked. It defines a project like Raku much more what kind of people it alienates immediately than what kind of people it attracts immediately. It's almost probable that doubling down on the "established values" will cement Raku into this niche, funny hobby project state... |
Beta Was this translation helpful? Give feedback.
-
|
Only one participant in this discussion have I not previously recognized as a member of the community (as defined above). A question is: What are we trying to expand, the community or the user base? Yes, they overlap and will grow or shrink together naturally, but they imply differing activity by the recruits. Users may care little about the community which makes community less of a marketing asset and will dilute the perception of community with noise. (Hardly a pressing concern.) |
Beta Was this translation helpful? Give feedback.
-
I'm surprised to find myself, for the 3rd time in this discussion, replying with "that's a good – but dangerous – idea" (though I guess this time it was more of a question than an idea). It's an important question to ask ourselves. And it's true that some target audiences might have different effects on community versus user base; if some audience would grow the community more, that could be a reason to target it over another audience that would draw in more Raku users. But it's also a dangerous question for at least three reasons: First, it can be tempting to define "the community"/Raku contributors too narrowly. Yes, the community includes those of us who show up in discussions like this one. But it also includes everyone who contributes to Raku in the broadest possible sense – editing the docs, answering (or asking!) questions on Stack Overflow, donating to the Raku Foundation, blogging about Raku, encouraging their employer to use Raku in production (increasing job options for Raku devs), talking about Raku to other developers, etc. And by this broader definition of the Raku community, "expanding the community" and "expanding the user base" might have more in common than they first appear. Second, we never really know where the next big Raku contributor will come from. A small percentage of Rakoons contribute a disproportionate amount to the language, and some of these top contributors have come from unlikely places. In a way, each Raku user is a bit like a lottery ticket, where the payoff is a new top contributor – and there's something to be said for having as many lottery tickets as possible. And, third, we want/need Raku to be sustainable economically. (I've been thinking about that a lot for a while, but especially recently since thebb linked to The Economics of Programming Language's presentation #raku IRC channel.) This is too big a topic to get into here, but there are at least some paths towards sustainability where non-community-member users would help make the community itself more sustainable. |
Beta Was this translation helpful? Give feedback.
-
|
This is a useful conversation. Following on from @niner 's point about having projects that use Raku, and generalising a bit on @0rir 's point about knowing the 'communities' or 'markets' we are ourselves already represent, we need some systematic information about the way in which we use Raku, which modules/functionalites we find most useful, what is the best way to describe our IT-related occupation (I'm not sure quite how to ask this in a more correct or general way, but what I mean is something like: software engineer, hardware engineer, data scientist, software hobbyist, academic etc). Suppose we set up a survey to send to all the list servers etc that we have access to, what would be good questions to ask? |
Beta Was this translation helpful? Give feedback.
-
|
As important as the 'communities' ... we ... represent is the what drew us to Raku. I pointedly say Raku, not because Perl 6 was bad marketing-wise but because that time span is more than long enough for analysis. |
Beta Was this translation helpful? Give feedback.
-
|
JJ Merelo's, annual Raku surveys were a good way of finding out the who/what/why/where of Raku's users. It seems the survey was last run in 2020. A suggestion is for the RSC to restore the annual survey as a way to understand the current audience. I'd like to encourage the RSC to be bolder, however. It's pretty clear that Raku is not taking off organically - the competition for developer-mindshare is just too fierce. In 'start up' speak the minimum viable product (MVP) has not found product A suggestion for a first pivot is to focus on a single new audience (e.g., solopreneurs, AI prompt writers, devops, CS200 lecturers etc).pick() and offer Raku-powered solutions to their problems. We may get it wrong. That's OK. Provided feedback loops are in place, we will be Once we have initial traction with one audience we can move on to the next audience. Given Raku's flexible and extensible design it won't take many engaged audiences for it to start growing organically. |
Beta Was this translation helpful? Give feedback.
-
|
@nige123 : On leadership and guidance, I agree with @codesections . Indeed if the RSC were to be more dictatorial and make binding decisions that affect everyone, community members would start ranting about bad decisions. So, to get things done, both from a pragmatic point of view, and because the Community wants to work this way, is to get some consensus in community discussions, such as this one. We are approaching a good point in time, with a major upcoming release, for another set of PR initiatives. As for focusing on a single audience, I think that might work if we as a community could direct the attention of volunteers to work on things that would attract that one audience. Alas, volunteers work on things that they are interested in. I have a view about what Raku could be used for and where it is outstanding (multilingual software and documentation). I am in my own way working in that direction. But I dont think that everyone should do the same. I think that Raku is a good fit for two populations:
Corporate software because Raku is written with a view to good documentation, software that expresses functionality, test-driven software development, and the ability to interface with existing libraries (I have written standard Raku code that interfaces with a C library, but I have never been able to do that in another language). Managers do need to be able to see the product their programmers are working on without needing to be language geeks to understand the code, and also to have measurable outcomes. Teaching code because Raku can be used to write very simple programs, then can be used to express different software paradigms. I am seriously considering writing a book about coding for my grandchildren. However, we need volunteers to help make the case for different audiences. It is not something we can magically create by throwing money at it. Also we need Raku community members who can say in discussions like this something like: my company would use Raku if .... [fill in the blank] existed or was better etc. If we have some concrete endpoints to hit, we might find ways to fill them. For example, next year's Google Summer of Code program has just been announced. We can submit proposals. So, if we had some targets to meet, we can pay people to achieve them. |
Beta Was this translation helpful? Give feedback.
-
|
@finanalyst thank you for sharing your thoughts!
In a corporate environment programmers come and go, so anyone should be able to read what other people before them wrote. Raku is not like that, it's just the opposite: Raku is for the artistic programmer, for people who want to express themselves, not for employees that write programs with the implicit perspective that someone else will maintain them. Maybe data scientists, data analysts, and researchers may find Raku a handy tool, since they deliver data, not programs. |
Beta Was this translation helpful? Give feedback.
-
|
@finanalyst documentation is a big marketing opportunity. It's often the case that module documentation concentrates on the solution space (typically in English only), however, search engines are looking to match with the problem space (e.g., how can I read a CSV file"). If module authors could document their modules in terms of the search problems they solve rather than simply describing the programmatic interface they expose, this could help Raku's search engine (SEO) game a LOT. A consistent documentation format for modules that begins with the top search problems a module solves would help SEO and the hoomans too. Users naturally search for problems in their own language, so multilingual documentation is a must. Large language models (LLMs) will slurp this up and ultimately point users back to Raku. |
Beta Was this translation helpful? Give feedback.
-
|
Sounds like a great iidea to me. I would love to see an example and format ideas. META6.json already has tags, but you may also have meant a more pointed blurb in the README on Github, or something similar. |
Beta Was this translation helpful? Give feedback.
-
I'm sure we would 😀 In fact, the rest of your comment provides a great illustration of that – not to mention showing that the RSC doesn't have this all worked out in advance and needs to build consensus just as much as the rest of the community. You see, the two audiences you identified are, imo, two of the last audiences Raku should target (though, of course, discovering that I disagree with you on this point doesn't at all diminish my respect for you, Richard). If the Raku community reaches a consensus that we should target corporate software and teaching programming, then I will (reluctantly) support that decision and help Raku attract those users; once it's settled, it's settled. But if the RSC "just picked" those two audiences, I would be pretty pissed – I try not to rant, but I'd definitely be tempted ☺ Here's why: Corporate software is a bad audience for Raku because corporations want something that Raku isn't, and any move to make Raku more like that would make it worse for non-corporate users. Specifically, software development at large corporations has three characteristics:
This means that corporate users want languages that enforce a single, uniform style (so that code written by one person on the large team reads the same as code written by someone they barely know). And they want languages with simple, familiar syntax (so new hires can learn the whole language quickly – or, even better, already know it). And they want languages that have strong safety rails/that make code review easier (to limit the damage done by the incompetent or lazy). Raku doesn't do any of those things; in most cases, we do the exact opposite. Further, any attempt to make Raku do better by those metrics would, I believe, break much of what makes Raku amazing. (I talked more about this in the Imagining the Ideal Language for Writing Free Software talk I linked earlier. I suppose I ought to turn that talk into a blog post so that I can link it more accessibly.) Targeting Raku to people just learning to code doesn't seem like nearly as bad an idea – in that it wouldn't risk making Raku actively worse ☺ But I still don't think it's a good idea. That's because Raku is a very unopinionated programming language (Timtowtdi!). That's great for programmers who have developed their own opinions, but isn't ideal for people learning their first programming language. It's like with school – we teach kids "always start your paragraphs with a topic sentence"; "never start a sentence with a conjunction"; "don't use sentence fragments". But then, when they've learned to write better, we tell them, "actually, nevermind. You totally can". In the same way, for someone just getting started, it's great to use a programming language that tells them "there's exactly one way to write this function, and I'll give you a compiler error if you break any rules". (And then, once they've gotten past that first step, they can switch to Raku and start to consider which of three or four ways of writing that function is actually clearest in that particular context). That said, I agree with what you said about Raku being used to teach multiple paradigms. I think Raku makes a great third programming language, but I'm not sure that's really a target audience in the same way. |
Beta Was this translation helpful? Give feedback.
-
|
This thread has a ton of great discussion (as did the Raku Governance brainstorming session at RakuConf, which I owe the community a blog post summarizing, which should be coming soon). I'd like to respond with three broader point; then I'll have some more specific replies. ① First, know thyselfAs a community, Rakoons govern ourselves primarily by consensus. But it's often hard to distinguish between a genuine consensus and the opinions of the loudest voices; in my opinion, we'd be much better off if we, collectively, had a sense of our community's consensus (or lack there of) on different priorities/values. So I strongly agree with @nige123's suggestion that we bring back the Raku Survey – and, hopefully, in a form that provides more insight into where the community is. (This is something that the RSC has already briefly discussed; expect more info soon). I'm optimistic that a survey can help answer at least some of the questions @finanalyst posed in the OP (along with others). For some questions, a survey may reveal an existing consensus; for others, it might serve as a starting point to reach consensus. ② Raku has some moneyWhile I agree that Raku doesn't have nearly the resources of corporate-backed languages, we do have some limited cash, especially in the form of an Raku-specific fund at The Perl & Raku Foundation. We need to think very carefully about how we spend that money – every That said, doubt that the correct amount to spend on marketing is $0. The Raku community contains a large number of professional programmers who generously donate coding work; we have far fewer (no?) marketing professionals who donate time in the same way. So we might need to pay for at least some of that work, if we want it done well. As a community, we should put some serious thought into what work would and would not be worth paying for (I personally am very unsure and want to do more research on this point). ③ Consensus-driven ≠ design-by-committee (of all Rakoons)When designing and implementing Raku (and community-owned tools like Rakudo and Zef), we make the big decisions via community discussion and consensus. But when it's time to implement that decision, it's almost always one person (or a small handful) who writes the actual code. The rest of us benefit from that implementation, even if the code wasn't written exactly the way we'd like or makes different tradeoffs in terms of performance vs. clarity or whatever. Similarly, with marketing/etc. it's important to decide the big-picture questions by consensus as a community. Things like values, target audience, what Raku's general "elevator pitch" should be – all the stuff that we're brainstorming about in this discussion. But, at some point, we'll have reached whatever consensus we're going to reach and it'll be down to implementing that consensus. Things like deciding on the exact wording of marketing materials, which community resources to link to and from where, all of that stuff. At that point, it's equally important that individuals feel empowered to do the actual implementation work without having it bike shredded by the whole community. I expect that achieving that will mean delegating overall responsibility for release marketing to a small group (or perhaps single person, if anyone is willing/able to take on that much work). That small group could be the RSC but I'd prefer that it not be – the RSC isn't really designed for that sort of role, nor were we selected for it by the community. Instead, I'd prefer some sort of "release marketing pumking" group or similar (which could of course have some overlap in membership with the RSC). Or, at least that's my ¢2 (and, I should add, just mine – I haven't discussed any of ^^^ with other RSC members; I have no idea if they'd agree or not). I'll post my more specific responses as replies to individual comment threads. |
Beta Was this translation helpful? Give feedback.
-
|
This lightning talk looks at ways of improving search engine optimisation/marketing (SEO) for Perl and Raku. https://www.youtube.com/watch?v=VS_IS_omAV8 I'm no longer suggesting a dedicated website (e.g., stackoverflow + rosettacode + raku.land). A suggestion is for the community to adopt a documentation format that is AI, SEO and human-friendly. The documentation format emphasises human problems <=> Raku solution pairings. |
Beta Was this translation helpful? Give feedback.
-
That's a pure myth that is so wrong it's almost comical. |
Beta Was this translation helpful? Give feedback.
-
|
@0rir I don't think this is either the place or the time for that, honestly. There are broad statements being thrown around about the killer feature of Python and myths and all. These things have to be taken with a grain of salt, or at least not 100 percent seriously. My remark also has to be understood in that context. The overall sentiment is not new; you can see it in a lot of issues I have opened but if you are curious, I think we can find a way to talk about it somewhere. |
Beta Was this translation helpful? Give feedback.
-
|
Generally, I think technical improvements or creations are not on the issue of marketing, so off-topic here. Python appears to be the most popular language, only dwarfed by the group of C and its early progeny (C++, Java, Javascript, C#). All these languages embrace simplicity. The progeny by leveraging the dominant C language made themselves easy for a large group. Raku is not so simple, and that should effect our goal setting. We want to accomplish something market-wise; we need to set some goal post. ( @2colours, since we are still in discussion here, rather than mention you in #404 to bring it to your attention, I'll mention it here.) I'm not sure to what that refers in the time for that. I guess you mean, this is not the place to give an example of good management. If that is correct, we disagree: here people are accepting criticism, evaluating it, and trying to fix things. So this is the place, to refine complaints so they may be reasonably acted upon or rejected. You have some ideas: some goal for Raku and that Raku is managed poorly. Without any standard or control, with which to compare our management, we might as well declare it the best possible. |
Beta Was this translation helpful? Give feedback.
-
|
@0rir I meant much broader than that. It's not the time to jump from casual "box-to-box" remarks to some fully blown analysis of the situation. Also, let's keep in mind that I am fairly familiar with the problems of Raku and how they probably applied to Perl as well at its peak, and not remotely as familiar with a lot of mainstream languages that seem to do alright, so it would be relatively easy to pinpoint the existing problems and quite hard to pull off some immediate remedy. Having said that, I think you can see how a lot of mainstream languages work, including languages like Javascript, Typescript, Python, Rust, Go (I hate to say it but for its own purposes it does work), C++ and probably many others. I would say, even Free Pascal works in its own way. One particular example I really like is PHP: it started off as a "joke language" and they are really illustrating that improvements are possible, even at design level, and using really oldshcool RFC processes. |
Beta Was this translation helpful? Give feedback.
-
|
I was not asking for a for a grand analysis, but just prompting you to clarify your complaint enough that it might be understood and actionable. From what you have said, I guess that you are criticizing language design and development activity. If that is so, we are off topic here. |
Beta Was this translation helpful? Give feedback.
-
|
@0rir the goal wasn't to be "actionable" and if these problems are not already "understood", I don't think there is any point in running extra laps. |
Beta Was this translation helpful? Give feedback.
-
|
@2COLORS The same set of behaviours can be viewed from different
perspectives. Being user-oriented and seeking to comply with user demand
could also be viewed as manically creating new user options.
So let's be kind on ourselves and recognise that all pressures to do
something good can be taken to extreme. Finding a moderate path is not easy
because there is always more than one to choose from.
Also lets step back and look at the development of programming languages
from the perspective of human history. They have been around for about my
own life time. after a period of intense growth and development, all
innovations slow down and move to a slower pace. At that point the focus is
not so much on new bleeding edge developments, but finding ways to be more
efficient for users. I'm trying to say that the goals of language design
now are very likely different to what they used to be. Of course the media
gurus who think the know everything will continue to parrot what used to be
true.
Raku is fundamentally a good language design. It may not be what
fashionistas want. But it is good for writing well designed and documented
software.
…On Sun, 19 Nov 2023, 22:12 Márton Polgár, ***@***.***> wrote:
It's hard to not see the overall tendency that languages maniacally
creating options for the user are dropping, or need some huge selling point
to compensate (confer C++ and Julia, and then even C++ is kind of uncool
these days). And I'm not sure how much this is a rule but languages that
maniacally create options for the users are not managed in a sufficiently
professional way. This basically describes the whole Perl bloodline.
—
Reply to this email directly, view it on GitHub
<#395 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACYZHFRCJ47NVKJRWK57G3YFJ75VAVCNFSM6AAAAAA6XWCJUCVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TMMJTGY3DG>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
It's interesting to read on the Python Foundation's website how they experimented with 'advocacy' but that in the end ... The lesson learned from this experiment is that, although many individual advocates for Python exist, the Python community as a whole is not interested or able to engage in organized advocacy. On the other hand, funding specific projects aimed at promoting Python is a fruitful way for the PSF to approach advocacy in the future and the PSF board is always open to new proposals in this area. Maybe it's just too hard to get everyone on the same page in regards to brand values and specific marketing campaigns. A suggestion then is for the RSC to continue to encourage general Raku advocacy activities (e.g., conferences, local meet ups, blogging, stackoverflow answers, advent etc) and to sponsor/support larger marketing projects on a case-by-case basis. |
Beta Was this translation helpful? Give feedback.
-
I'm taking what you say as literally 100% true, but not being pedantic, when I say I know we're on the same page when I say what may sound like the opposite. Furthermore I know you will agree, hopefully immediately, but if not, after an exchange. To wit, I think it's certain that as of 2023 it's so easy to get everyone on the same page in regards to brand values that it's almost stunning. And there's no reason to think we won't be on the same page with regard to marketing campaigns too, either already, or by the end of 2024. Most of the concepts of top down marketing were dead in the water by 1995, they just didn't know it. Now they know it. BTW, whoever heard of Sam Altman? |
Beta Was this translation helpful? Give feedback.
-
This is a discussion prompted by the 'Focus' thread on Raku-Steering-Council and conversations during the 2023 Raku conference.
This is the first post in Problem-solvers in the 'discussion' format, so having the discussion here is going to be a bit of an experiment for most of us. All comment, feedback, contributions are welcome, remembering -Ofun (optimised for fun), inclusiveness, and cooperation.
Some preliminary remarks:
Some terms I will use below. I know not everyone may agree with the distinctions, and its possible the Community may come to a consensus to describe things differently as the discussion progresses
Clearly, PR activities and Marketing can (must) be done by individuals, but in order to avoid chaos and confusion, there needs to be some Community consensus above them. Branding - both in terms of the actual symbols/styles that are adopted and what should or shouldn't be included in branding - is very much affected by individual taste, and some people are very strident about what they feel is right.
Because it is obvious that there are issues of taste or opinion, if an individual begins to make some contribution, it is very easy for others to find 'mistakes' in their work. Consequently, talented people in the Community do not offer to contribute - and that may be another reason Raku is under-appreciated more generally.
It is not possible for the Raku Community to leave PR, Marketing, or Branding to some 'authority', such as the Raku Steering Council, or the Perl and Raku Foundation, or even to throw money at someone else (a consultant or agency) to do it. We don't have the resources, either financial or personal. So we need to leverage the resources of the Raku Community.
The aim of this discussion is to facilitate a process and brain-storming to move towards a Community consensus on Marketing, PR, and Branding. With a consensus, individual members of the Community will find it easier to make contributions, however large or small. In addition, trouble-makers (unfortunately some people like to be contrarians to 'see what happens') will need to take into account the Community's consensus, rather than just targeting some individual's contribution.
To start the discussion, please find below some issues that have been raised and some questions for Community feedback. There are repos and issues elsewhere containing ideas. The idea here is to coordinate connected issues. The questions are as simplistic as possible, even if the answers may seem obvious, but by asking them, we are like to get a more exhaustive set of responses.
I'll end here.
Beta Was this translation helpful? Give feedback.
All reactions