Updated 2011-01-20 22:45:40 by amcp ▲

Discussion of Tcl Marketing.

I hope I didn't do an un-wiki'ish thing by moving the discussion portion of the page here, but I want to keep the other one targeted at "things to do", leaving this one to discuss them.

Discussion:

  • Don't get engineers to try to figure out marketing. :-)

davidw - well if you don't figure it out, someone else will and will eat your lunch. Look at PHP and Python and their present popularity, for instance. You have two ways of looking at it: they created better systems faster than Tcl, or they had better product marketing.

LES I always thought that Python got so popular because it has OOP. I don't like either (neither Python nor OOP), but most programmers absolutely love OOP. Java is another good example. And all the excitement around Microsoft's next-gen shell, codenamed Monad.

LV Two thoughts. In the past, there have been these discussions, with some people saying why bother and others saying tcl will die if not properly marketed. There is one primary reason that a technical person might care about tcl being properly marketed - I've personally seen cases where Tcl would be a nice fit for solving a problem, but it was rejected because it wasn't a real programming language.

On the other hand, arguments about marketing tcl to get more programmers, etc. are less interesting to me, as I tend to look at things from a technical point of view, and there are more than enough people asking me questions about tcl right now... I'm not looking to increase my work load.

davidw

The reason you should care about that is called "network effects", meaning that the more people use something the more valuable it is (like a telephone network, no good if you can't talk to anyone with it). This is so for programming languages because if things go well, those users become contributors and create things that in turn, you can use. Libraries, documentation, tutorials, and other materials that make your life as a programmer easier. When something is well known, it's of course also easier to sell it or sell skills based on it. You can make a living as a Java or [VisualBasic] consultant, selling the ability to write code in those languages, but you can't do that with Tcl. You *must* sell the ability to get some particular task done, which is doable in Tcl, but it narrows the field some...

Of course, were that the only factor, no one would use anything but visual basic, but it's not an argument to be brushed aside completely, either.

That's why "marketing" matters.

LV I understand your viewpoint - but my current view is that this isn't something that I'm concerned about. I don't see people marketing FORTRAN, COBOL, C, C++, etc. and these languages are still around with contributors, etc. Same for Tcl - I see regular announcements of new programs, updates, etc. Yes, the community is no longer as social as it was - see the stuggles that have occured the past couple of years for conferences. But then, how many C or FORTRAN conferences do you see advertising? Yes, Python and Perl do more marketing. And perhaps they get more traffic out of it. Right now, Tcl doesn't have a layer of people who find the idea of marketing the language interesting. Until someone steps forward to do that, I suspect the only marketing that is going to occur for Tcl are the people doing consulting work and Activestate.

davidw C and C++ are orders of magnitude more widespread than Tcl. They have many orders of magnitude more code available, and zillions of people that know how to use them. They are so ingrained into so many things that they just aren't at risk. Sure, they may be turfed out of some field, but the areas they are used in are staggeringly large.

Tcl is a very different beast than those languages. It's much younger and not nearly as widely accepted. So you are really comparing apples and oranges.

I'm talking about things like conferences. Sure there are no 'C' conferences per se [ CL interrupts: C still has standards meetings, at least], but zillions of conferences where C code is discussed for some problem domain. Tcl doesn't have this (as far as I know at least...maybe some field like EDA has a lot of tcl-talk).

Tcl isn't that bad off in terms of libraries, users and such. But not much new is happening because it's not seen as an interesting or promising platform. That may be ok if it does all you want right now, but you should also consider the future, where you might want access to new libraries or technologies, or to use Tcl in new environments. It won't be there, because the people working on that stuff won't have considered it. And at that point, if you want to get your job done, you will have to migrate to another environment in any case.

One of the things that makes C so enduring is that it does have people using it both for "old guy with family just wants to get the job done" and "young college student hacking at night" projects. You can't just pick one of those and ignore the other.

Maybe BeanShell is in the same spirit but for Java. To be honest, I use Tcl and Java and BeanShell is quite a great Tcl-like in spirit (the author of BeanShell used Tcl and wanted the same for Java). More and more, I find myself using BeanShell instead of Tcl because I know the libraries being provided.

yeksoon I will make an analogy. If Tcl is a business entity, and it is already matured in terms of business growth, as CEO of Tcl, what would you do to ensure continuous growth of Tcl?

Example, Starbucks is saturating in their business of selling coffee. Hence, they start acquiring HearMusic.

Tcl is a matured language, and without a doubt the community stands by it. If being matured is not enough to attract-and-retain developers, then the focus should really be on innovation and marketing.

If one is to move Tcl forward through innovation, what will this innovation be? All other marketing activities will hence revolves around the innovation.

LV Tcl is not a business, however. There is no pressure to set goals and reach them. There is no rewards paid to those who have been pouring in thousands of hours of their lives into Tcl with little thanks or recognition paid. There are few who are being paid a salary or provided other recompense for moving Tcl forward. There's no single individual who provides a unified vision for Tcl's future. There's no benefit for increasing the number of users of applications written in the language. Certainly, however, there is a potential benefit if one could figure out a way to increase the number of individuals who contributed their own time for improving the Tcl environment in a positive manner.

I wonder whether there is some other parallel that might be more accurate a comparison for Tcl. For instance, perhaps, rather than comparing Tcl to a business, it should be compared to some government department.

davidw I've given talks, written articles (one even featuring the TCT to try and give them some publicity), hacked code, but ultimately it's got to be someone with some "authority". Dave Welton, "Tcl user" doesn't cut it for people. It doesn't open doors (Apache Software Foundation does, though). TCT might.

I don't think a business is an entirely stupid comparison. Maybe a product.

Larry hits on a few points:

1) the frustration of spending a lot of time on something with no thanks, recognition (or presumably cash, which never hurts either). That's exactly what I'm talking about. You get that kind of recognition if your product is marketed well. I get way, way, way more mileage out of being associated with the ASF (Apache) than anything directly Tcl related. And they are free software, just like us.

2) no benefit to having additional users

3) unless they can be converted to contributors

Obviously, if you have 0 users, none will become developers. You need a broad comunity to attract new blood. If the community at large shrinks, so does the pool of potential future hackers. How to turn them into hackers is another subject entirely, and I'm not sure whether I have the knowledge to say if the TCT has done a good or bad job with that - it may not be an easy thing to measure at all.

Sarnold I first realized Tcl was a great language when I saw a script written in Tcl, that configured an Oracle database. That was the point I began to think that Tcl is a real programming language. Before that I just thought Tcl/Tk as a simple (yet powerful) framework to do easy GUIs. Personnally, I think there should not be a language war. I recognize C, Java and Python strengths, and also their weaknesses.

I do not think that Tcl is (so horrible to say) dead. Many people say : 'XYZ language is dead', but I think there are still monthly improvments in many, many languages. (see C99 for instance) And Tcl is one of them.

VK: I want that impolite notice about Perl "still very popular, but dropping off." go away. It will do no good, yet better arguing will do more good: please show your arguments about perl losing positions. (I am convinced quite opposite, please convince me otherwise, but with good arguments)

davidw: Just like Tcl, Perl is no longer the hip, popular language that it once was. Also similar to Tcl, it has been surpassed in what was once a big strength, web programming, by Java and PHP. This does not mean that it's going away. It's probably still growing in use, but in terms of percentage compared with other languages, from what I observe, it's no longer as popular as it once was, and I base the 'dropping off' comment on new projects written in Perl. There are less than there once were. It's hard to come by hard data either way, but as an attentive observer of the open source community, it's what my nose tells me.
    (Quoted from Above) I've given talks, written articles (one even featuring the TCT to try and give them some publicity),
    hacked code, but     ultimately it's got to be someone with some "authority".
    Dave Welton, "Tcl user" doesn't cut it for people.  It doesn't open doors (Apache Software Foundation does, though).  TCT might.

XX This is one problem the TCL community has, and quite frankly, doesn't have many vocal members that think it is a problem (while having a few that outright oppose any kind of organization, especially if it might -gasp- handle money). How many times has this conversation taken place:

(Non-Core Person) I have this idea for marketing TCL or improving the marketplace in some way. (Core Person) Well go to it, do it, you don't need our blessing.

There hasn't been a problem with the core team standing in the way, but what they don't realize is that no one will listen to Joe Whammy, "TCL User", so the idea might as well be sent to the rubbish bin. The core team members rightly want to focus on the development of the TCL core. That is what they are there for. unfortunately, it is also expected that they take the reins in shaping the direction of TCL in other areas. Leave the rest to Activestate has been more like it.

This is the height of folly. It should be obvious that a second "authority" needs to exist. Not to take power away from the TCT (which should operate independently of marketing concerns for good reasons). But to go out into the world and *gain* power for the TCT, the TCL community, and everyone involved. See, people that don't have to worry about hacking the core might have some of their "TCL time" left to actually make hay out of some of these goals. Expecting core members and companies that benefit from TCL to do it hasn't worked very well, and certainly isn't ideal.

The idea of a foundation has worked well for other software interests, and while it may not be a Good Thing for TCL, something along the lines is definitely in order. TCL is already, as Larry Virden puts it, much like a government agency. In my opinion, the BSD licence and history of TCL's development process make it a prime target for an organizational structure. This would help enable several things:

  1. That no one company gains too much influence at any point in the future. TCL has been lucky in that the companies associated with it have acted as stewards and benefactors rather then pure exploiters. It would be foolish to wait for this luck to run out before addressing the risks.
  2. That the "image" of TCL can progress at a rate comparable to that of the core, rather then regressing as TCL's technology advances.
  3. That the resources of the community can be applied in a cohesive, unified fashion towards concrete goals. These goals gan be voted upon and then delegated, along with the appropriate resources and "deed and title" to make them happen.
  4. That the community can be accounted for aside from a loose collection of testimonials and a page of TCLers. Membership has its benefits, and efforts to "sign up" indeviduals at the user and developer levels plus companies would be a valuable asset.
  5. That the TCL language has a "face" that it can show to companies to help do things like connect them with reliable support services, assure them of the types of things corporate types like to be reassured of, to answer questions officially and without the "take it or leave it or hire me as a consultant" ring to it.
  6. That the TCL programmer has a resource to help him with issues like freelance employment, job creation. etc.
  7. That the future of TCL has more then just solid engineering behind it. That it will have a viable image, a competitive bite and hopefully a war chest to help squash the competition and make TCL the scripting language *of choice*. Yes, it is possible. TCL is that good no matter what some hippy in Boston has to say about it ;-)
  8. That Python is an historical part of TCL and should be reunited with its historic people.

RS notes that Python is not a historical part of Tcl - they just grabbed Tk for Tkinter... Tcl is a late chip off the LISP block, while Python is in the Fortran/Algol/C/Java heritage :) CMcC notes that the erudite XX was making a joke, suggesting that Tcl annexe Python as Germany annexed the Sudatenland, as "ein historisches Teil von Deutschland" or something. I think we should also probably invade FORTH, as nobody will object to our occupation of a reverse polish language. Presumably because we need room for expression.

Lars H (knowing that this is probably rather an issue for Tcl Heritage): Please explain how Tcl is more a "chip off the LISP block" than a descendant of e.g. C? My impression is that there are rather large differences between Tcl and LISP, perhaps even larger than to C! - RS: Tcl has lists as core concept. Code is data. Tcl has dynamic storage management and typing. Every Tcl command/control structure is an S-expression (a list). Granted, Tcl uses flat pointer arrays in place of CONS cells, but in practice, I've hardly seen that implementation detail matter.

davidw Hi - who are you?:-) You have some ideas worth thinking about. As far as foundations go, the Apache Software Foundation is something that might be worth considering, and I could certainly explain some of the benefits (as well as drawbacks), being part of the group myself. But it would have to be the core team to want that.

XX What is important is that I agree with your sentiments and believe that the future of TCL is worth fighting for. I wouldn't mind a brief summary of your pros and cons being expounded in this discussion, if you are comfortable with that and have the time.

It goes without saying that any sort of organization (and there are many structures this might take) would need the support of the TCT and its individual members. Any successful organization would need to draw to some extent on the TCT's "authority" initially, as well as work closely with the TCT to ensure that TCL's image and marketing angle advances in tandem with TCL's technical development. Cooperation is therefore essential to success of any significant measure.

RS There was a Tcl Foundation some years ago, and it faded away for lack of involvement from paying members. The currently most vivid things are this Wiki and the Tcl chatroom, but they have no fixed organization, they just adapt to the interests and needs of Tcl users, provided by Tcl users unorganized and unpaid - but still, it feels good...

XX There is no doubt...can be no doubt, in the mind of anyone without an agenda, on the success of the Wiki. You, sir, have been no small part of that, and I have since I have been following the Wiki looked forward to your consise, always eye-opening and never boring contributions. Your generosity stands as an example to all. And the chatroom serves its purpose, but neither can take the place of what Mr. Welton and myself are getting at.

If there was one adjective I think describes an impression that is easy to take of the technological resources of TCL and TK, "scattered" or "confusing" would be a toss-up. This is but one problem that marketing can cut its teeth on right away. Exciting concepts like Starkits, Critcl, the VFS infrastructure, and a wide range of other TCL innovations need to be unified and leveraged against the offerings of other scripting languages, and the practical problems facing developers today. Organized libraries, things *outside* the core of TCL. Not that organized means centralized (in fact, a case can be made that the need for centralization is the first obstacle to overcome for enduring order) but a centralization of *effort* will be required.

One thing that impressed me greatly about the TCL community initially was the uncanny percentage of members that posess within themselves the usually rare ability to think outside the box. Look at the technologies mentioned above, applications like tkcon that turn the interpreter in on itself for the benefit of the developer, indeed the very "invention" of TCL and TK all are examples of this excellent ability. I can't help but think "if only..." every time I survey this wiki (and find some new dark corner...) and CLT.

Anyway, blah...blah...blah. I would be interested if RS or someone else "in the know" could contribute a summary account of the birth, life and death of the previous TCL Foundation, as well as any insights about the attempt. A quick Google didn't turn up anything for me. I think such an account could really help any future efforts that might be suggested.

MR It went under the banner 'Tcl Consortium' ... was around from (I believe) 1997-1999. While it did a few things, it never gained significant traction. A big part of this (IMHO) had to do with timing, as this started up right around when Scriptics was launched. Originally, before all the XML stuff, Scriptics was there to promote Tcl to the developer community, develop tools, etc. So you had essentially two organizations who had as significant goals to promote Tcl. Scriptics also had a good chunk of the "high profile" leaders in the Tcl community. Most companies and individuals looking to help support Tcl in some way found it made more sense (and was easier to justify to higher management) for them to purchase licenses for the TclPro products that Scriptics offered then make essentially a donation to the Consortium. So in the light of those options, I think it was hard for the Consortium to build up any steam. After Scriptics had moved away from Tcl as a main focus, there was still that hole left behind, which is I think still there today.

davidw Wasn't the Tcl Consortium sort of a corporate-oriented group, similar to what OSDL is these days for the Linux kernel? I wasn't very involved with Tcl at the time.

In any case, as a concrete course of action, the Apache Software Foundation would have ramifications regarding various aspects of Tcl:

  • More formal organization. The TCT would be transformed into the PMC[1] of a Tcl group.
  • Infrastructure - the ASF has a reasonably good infrastructure group.
  • Conferences - the ASF does a yearly conference in the US, and depending on how things are going, might do a European conference. I'm not sure how many people went to the last Tcl conference, but throwing in our lot with a larger group might give more people an incentive to go, and also get people going for other reasons to check out Tcl.
  • Visibility - the ASF is a very highly regarded organization, and has a lot of visibility in both the free software world, as well as in corporations. "We" no longer do just web stuff, either. SpamAssasin, for instance, is now part of the ASF, as are numerous Java projects that have little to do with the web. ASF is not sourceforge, and it has a bit more of an air of exclusivity to it.
  • Culture - the ASF is much more BSD'ish than GPL'ish, culture wise. I think the culture would be a good fit.
  • License - this is probably one of the big issues. The ASF license is corporate friendly, and is similar to the BSD, but has some extras, such as requiring that contributors be cited... read for yourself[2]. Keeping the original Tcl license might be negotiable, I'm not sure. (DKF: Needs a legal wonk to assess whether the licenses are compatible enough for current uses; they're close enough that I can't tell for sure...)
  • Money - the ASF is a non-profit corporation in the US, with no paid employees. As such, it can accept donations.

There are many things to consider, but I think it is something that could be made to work. Another potential non-profit umbrella group is SPI - Software in the Public Interest, which functions as the legal organization behind Debian Linux. I think it would be less of a fit culturally though.

I'm not sure a foundation is really the core of the problem, though. I think visibility can be achieved even without it. But it is something that has to come from the core team. People rightly look to Larry or Guido or whoever for guidance. Tcl successfully transitioned from a single benevolent dictator to an organized group, but we have yet to bring back the PR function that the "single leader" model has.

MR Agree on previous paragraph. Even some fairly basic marketing decisions (e.g. the positioning for Tcl) are not conducive to community-wide resolution. Some sort of smaller group or individual, vested with the appropriate authority, needs to be able to decide those kind of things (as with other things Tcl, after collecting input from the broader community).

XX I agree as well but think that authority and decisiveness are the key factors, not the size, composition or even operating style of the "decision making body". Although personally I disdain voting bodies for executive functions, it could be made to work if thats what people and companies are most comfortable with. A lot of people fear that tyranny lies in wait behind every "dictatorship" and they may have a point. The can be little dispute, however, that a single individual "at the top" has advantages in the areas of deciciveness (hopefully), swiftness of action and the all-important potential-for-visibility. Its harder for a group to have a face then an individual, though an individual may well be used and be used well to give an exciting face to a larger and less interesting body of people.

XX I followed this link provided on the page 'Tcl Consortium' and have a slightly better picture of what went on there. It would seem that there were problems from the very announcement. I don't see how an organization can be expected to engage "outsiders" if it cannot even unify its own community to any large extent. One might even suggest that the Consotium was doomed to failure. Clearly any successful efforts would have to learn from the mistakes of this previous attempt. The first mistake was the notion of a Consortium at all. The TCT acting on behalf of "all" is a much better model for development then the implied "But we'll listen to you MORE" of the high-priced consortium dues.

There are several mistakes that I can see right off the bat. I'm sure some people might argue with some of them, especially since people involved with the idea are still around. To them I would only say thank you for your efforts, and given the climate and TCL's position at the time, I don't necessarily believe anyone could have done better. However, here we are - 2004 and the climate is drastically different. I believe that the ingredients for success are all there IF the community can be united and energized rather then handed the same old plate of tired corporate strategies. I'm sure that last comment won't win me any friends, but there is an important reason I take that risk to say it. It needs to be said.

A few comments on the previous efforts:

1. The idea of a technology consortium is the last thing TCL needs. The TCT, its functioning and its success are the baby and not the bathwater. The LAST thing they need is moneymen leaning on them to go in this direction or that. I know that money talks, and with a BSD licenced project those that pay vendors that are heavily involved with development will get more attention paid to their needs. However, formalizing and blessing these facts of life into official strategies is a Bad Thing. The current TCT/TIP engineering model works and works well because it balances against the influences I mention by protecting what is best about the language. One only need the core mailing list to see this in action.

2. Exorbitant fees
 - WITH -

3. Little tangible benefit.

The tangible benefits of membership in the consortium were dubious at best. Several comments to this effect can be found in the thread, and a reading of the announcement will confirm it. The one tangible benefit (TCL-Blast!) was such a good idea that people can still be found asking for it. But even with that more could have been done.

I don't think that any organization formed today should offer direct paid support or offers to "listen better" to someone's needs. First of all, its not clear that TCL is in a position to offer this with any seriousness anymore. But even if it was, this is best left to a free market of vendors. This is very implementation-specific, and any organization I can envision will not want to be so encumbered. Further, its not clear that even initial demand could be met in any realistic sense... too many of the target members offer support services already themselves.

As for the fees, it may be argued (as it was) that the corporate rates were little to corporations of any salt. That may be true, but even if it is TCL is not in a position to make such demands. What is needed is not money (that will follow) but involvement and excitement. So I would suggest that any "dues" or "fees" be determined from scratch and be based on the completetely different set of assumptions that is currently in play.

I think that the success of any organization will initially depend on the energy of volunteers anyway. Failing this, no amount of money will make this work. I am excited because I see in the TCL community a diamond-in-the-rough and in TCL an unbeatable "product". That a vibrant and self-sustaining marketplace could be "germinated" around it I have no doubts. Others will have their own reasons - but the bottom line is that so much of what could be done initially can also be done quickly and with *little money* or resources above and beyond what already exists (assuming the current resources do not diminish).

--

In addition to these "mistakes" there are also more factors affecting any actions today. TCL exists in a completely different landscape. When the "Consortium" was getting underway, Sun Microsystems was the major player in the field. Now it is ActiveState. ActiveState takes a much more ActiveRole in TCL and in my opinion this is a "Good Thing". I think (at least based on casual observation) that there is more trust between ActiveState and the community at large then there was with Sun. And for many good reasons.

However, there is a downside to this, in that many people just on the outer-rim of "in the know" think that TCL is an ActiveState product. Having no visible advertising except ActiveState advertising on the official web page does not help. And having the answer to "Where can I get official binaries?" be "ActiveState" doesn't help either.

There are other "problems" to overcome, and many have already been mentioned. I mention them again just to tie things in with what I am saying here. :

1. Many more competitors across the board and in TCL's traditional niche areas.

2. The setback of being "niched out" of a one-time target for TCL's future by PHP.

3. The miconceptions of TK as still being a Motif style toolkit in the age of EX-PEE candyapple shine. True or not it is believed by many potential users and developers to be true.

4. Overall scattering of what should be core assets and resources. This applies to third party extensions and underexploited core technologies that instead of changing the landscape of scripting are merely considered by many as another "cool thing" TCL can do.

5. Feel free to add any others...I probably will. There more that is known about the problems, the better the chances of actually solving some of them.

DKF: Notes on the above numbered points (bearing in mind that I can't market my way out of a wet paper bag...):

  1. I for one welcome this. More languages to beat. :^D
  2. Yeah, and PHP is despised by many many people. We can still win here, especially with the help of Rivet and tclhttpd.
  3. This will be addressed in 8.5
  4. An interesting point, and not something that's really much easier for anyone else. Every major community will have problems with this; I suspect it is one of the perils of success. OTOH, we should look closely at what should be in the core and what should not. Packaging and distribution technologies are relevant to this, but it takes more than technology to solve too.
  5. (add comments when items to comment on are added)

XX In reply to DKF's comments above...

1. You have an optimistic outlook, congratulations. This can be a difficult world to maintain that in ;-) from a practical standpoint, however, more choices adds difficulty to the task of increasing TCL's market share. While TCL can compete on the merits, my point is that the battle will be harder and harder fought as more alternatives reach maturity and gain market recognition.

2. I'll defer to your opinion on this one, as I don't know too much about the competing technologies. I would mention again that my suggestion was never that TCL's technologies aren't upto snuff. That's the reason I'm wasting my time here ;-). If, as you suggest and I believe, TCL can still win here, then it is better marketing that will close the divide, not better technology.

3. Will only be "addressed" if the technological changes are accompanied with some kind of marketing accompanyment ("TK8.5- Not your grandma's TK Toolkit" or something similiarly catchy and stupid would go a long way by itself). I shouldn't need to tell a longtime TCL'er like yourself that the problem TCL has had is getting the word out when it does come out with a groundbreaking improvement.

4. Agreed that there will always be problems bringing a cohesive quality to that which must, by its very nature, be distributed across a range of "vendors". Surely the TCT couldn't take responsiblity for every useful extension, nor would that me the right way to go about things. And you're right (and agreeing with me) when you say that technology alone cannot combat this problem.

I have many ideas about #4, some more "worked through" then others in my mind. For now, I will content myself with suggesting the following. Consider what changes could be wrought with standards-based branding opportunities for extension authors. The "tradeoff" for the author would be the requirement of a compliant structure *and* certain common marketing agreements. The "payoff" would be *official* (though non-core) status. Even something as simple as a common chart all exension authors are encouraged to use that would inform the user at a glance what he can expect in certain key areas (supported versions, stubs, cross-platform, etc...)

More on all of this later, but I would hope that at the very least the point is made.

Thanks for taking the time to comment, DKF. I hope that I can infer from this that you agree that this is an important discussion to have, if nothing else. Consider what a dramatic effect the TIP system had on TCL's development quality. Now consider applying the same kind of ingenuity to the marketing and image problems the language and community continue to suffer.

DKF: I did say that I can't market my way out of a wet paper bag. :^) However a number of the problems are interesting in that they have both marketing and technical aspects to be solved. Solving just one of the aspects isn't a solution.

And TIPs were invented because we (the TCT in general) were fed up of ending up with APIs in the core for which there was no documented reason. A goal is to record what people intended to do (instead of just what they actually did) and why they thought that was a good idea. I ended up in charge mostly because I got a working TIP system together and I was willing to do the work... ;^)

yeksoon To be successful in the minds of developer, Tcl needs to focus on one single core 'marketing message'. During the days of Scriptics, it aimed to be the 'glue'.

Java, when it started, focus on cross-platform as its main message with OOP as a sidekick (that is the way I view it). PHP focus on easy to use for newbies and for anyone who wants to do some server side scripting.

The 'glue' message has not been emphasized since the focus of the Core Team focus on making Tcl a better language. Such focus needs to be emphasized in 'landing' areas. Tcl Developer Site needs to show such emphasis, case studies, whitepapers are all part of the efforts needed.

edited: Just to addon, IBM site on its Automotive solution [3] provides different views to the user viewing it.

This is something worth studying. The developer looking for a more 'powerful' language is different than the manager looking for a framework, or solution. So Tcl the language is different from Rivet... but it gels together when it is used as a solution to business problem. Another example is probably AOLServer and OpenACS.

davidw This is an interesting article on marketing free software: http://www.freesoftwaremagazine.com/free_issues/issue_02/guerrilla-marketing/

An interesting comment from Robin Miller on the free software business mailing list:
    But the biggest barrier to effective marketing for open source
    projects is the, "Our stuff is great, and great stuff doesn't need
    marketing. And marketing is nothing but lies anyway," attitude so many
    FOSS people seem to have.

    Umm.... whatever.  Go on believing that in a world where inferior
    products commonly rise to the top of the marketplace while superior
    ones tank, and you may be happy but you will be WRONG.

This discussion seems to have died down...but I think that it is an important one to rekindle now, especially with the release of the hot new 8.5 series. Tcl needs serious image work, to create a public perception more in line with the facts about Tcl in 2007, to encourage development of new projects in tcl/Tile, to be an exciting choice for newish programmer types rather than a weird and crufty artifact. Tcl is great, but few people know it outside the close-knit tcl community.

Things that could use improvement:

  • the main web site. Surely among us someone is, or knows, a skilled graphic designer that can give it a real shiny polish and glow, and likewise someone to polish the language (the phrase "elite hackers" has got to go!). There could be sections on "famous applications using Tcl," a section on the state of Tcl in 2007, developer stories on how Tcl/Tk has made their life easy, etc. Make these sections easy to spot and hold people's attention while you point out how great Tcl is.
  • put a spotlight on the current hot projects in the community, as well as the upcoming improvements in Tcl, and update this regularly
  • put some community effort toward simple but attractive-to-newbies (i.e. lots of step-by-step "do this, now do that") tutorials and projects
  • make it EASY to find these things!

Is all that about Making www.tcl.tk a better place?

Sly 2008-01-14: Tcl is now mentioned on http://www.json.org/ and http://www.libsdl.org/languages.php

Guys... you should have done it as soon as these bindings were implemented.

Fabricio Rocha - 10-Apr-2009 - So, is anybody still up to this (quite interesting and needed) discussion? Or did the subject simply die in ignorance??

CMcC just read a pamphlette on selling stuff, and so wrote Why would I want to use Tcl? as a blurb.

WJG The Tickle community is good at telling each other about how well they've used Tickle to solve problems. That's fine but we need to tell others too. Its all a matter of habbit. Y'see, other coding forums, especially those dealing with GUI kits, have lots of people reading them because, as we know, other scripters don't have a native graphics front end. So, they get info on how to use other language bindings other than Tk. Tcl/Tk is a pretty complete package, but maybe nowaday that's the downside. If the 'apparent' choice is all or nothing, then, well 'nothing' gets chosen. My first piece of advice to improve the persona of Tcl would be add some vowels, 'Tcl' sounds so 60's and 70's. Its reminiscent of the days of the Apollo space missions when we were glued to the tele listening to and reading NASA reports rife acronyms such as LM, CM, ETA, EVA, LCRU. LRV, etc... etc... And those really ancient mini computer series numbers, PDP-11, blah, blah, blah. Would 'C' be called 'C' if it was invented today? Does anyone out there remember the C5? 'nuff said. Add some vowels! Who in the current age of new programmers would want to use PTHN, PRL, RB or L? They read like something from a text message!

AKM 2011-01-09 - Some comments about Perl that sound familiar: http://blogs.perl.org/users/su-shee/2011/01/and-suddenly-youre-hip.html

Siqsuruq - 2011-01-09 19:24:14

Personally I think TCL needs more end user software to be written. Write TCL/Tk GOOD SOFTWARE, witch end users like now, tomorrow it will be thousands of new users and programmers. TCL is great language but there is no END USER software you can use.

CliC 2011-01-10

I find this discussion interesting, though I'm not sure what the answer to Tcl's "popularity problem" is, or whether it is truly that much of a problem.

I found Tcl while looking for a capable, high-level tool that could generate portable, easy-to-distribute applications. Perl and Python and Ruby and Lua for various reasons didn't really fill that bill, at least not for my platforms of interest. Java was too much typing to accomplish too little work. Google led me to starkits somehow, which led me to Tcl and Tk. I'm still getting my head around the Tcl Way (watching the amazing things that some talented folks on this wiki do with Tcl helps), but I like it. I'll admit I had never given Tcl much though before, only passing recognition when I saw it next to that other vowel-challenged demi-word "Tk", apparently used as a GUI option in other languages.

If Tcl was more popular, it might get more developer person-hours with libraries (and possibly the core, if they were competent enough). But I'm not sure of that. Most "hip" languages today don't seem to me to be overall better than Tcl; they are just newer and/or they have some particular strength in one area that happens to be suited to a popular topic or problem (e.g., Ruby and Rails, Erlang and CouchDB/concurrency, Haskell and functional programming). In a (perhaps pathological) way I kinda like the notion of Tcl as "secret weapon", as Paul Graham for example has described his use of Common Lisp :)

Category Discussion