How to market[1 ] Tcl to make it more appealing to:
- software development business users
- inhouse business users
- freelance programmers
- science and engineering users
- application and desktop end users
- non-programmers of all kinds (that often make decisions for programmers ;-) )
What are some general goals?
- Show that it's possible to design complex applications in Tcl that don't get too hairy.
- Show that it's possible to design serious applications that have a GUI separate from the backend code (no Tk spaghetti!).
- When someone says that XYZ language is better - ask them why they think that, and how they arrived at that conclusion. Try and determine what factors (peers, press, job pressure) are most responsible for their state of mind. Then convince them Tcl is better:-) And report back to "The Borg" so that these concerns can be better addressed.
What are some concrete things to do?
- Create Tile so that Tk applications share a platform's look and feel. In Tcl 8.5, Tile became distributed with Tk as Ttk.
- Contribute to the Tcl Tutorial: tcltutorial
- Create "one object system to rule them all" or at least make a final decision about what will be done. In Tcl 8.6, incr Tcl will be included (with the underlying tcloo framework for those who wish another direction).
- Update the https://www.tcl-lang.org/ web site. Rather, it needs a facelift + regular content updates with eye-catching differences. (Some people think the web site is too corporate, or rather, too ActiveState - that discussion should be on the Tcl Marketing Discussion page though. If there is any agreement, we'll put it back here. - davidw)
- Contact 3rd party webmasters for Tcl related sites, extension authors etc. and get them to update their website. At the very least to reflect accurate information about the current state of Tcl and Tk and how their offering fits into the picture. Too many stale extensions still claim to work with a "current" version of Tcl or Tk. Too much stale information exists on the web, and any effort in this area is better then no effort. Even people that don't have the time are more likely to find it if asked politely, and in some tough cases, handed the html for the appropriate changes.
- Expunge as many as possible of the 8 million mentions of now-defunct or completely uninvolved companies associated with Tcl on the web. Mention of companies such as Scriptics, Sun and Ajuba should relate only to copyright discussions or a larger historical context. These are used as contemporary references in too many places, causing vast amounts of confusion and making Tcl and Tk appear to be like some technological hot-potato/black widow. This is a real problem.
- Consistent, easily available packages, both pure Tcl and C code. Consistent documentation as well. Certainly teapot is a source for obtaining and installing Tcl packages through ActiveState's teacup application. However, something similar is needed for documentation, etc.
- Give talks. This goes double for the core team, because being "core team" is something that will get you in doors to give the talks in the first place. This is a good way to chat with potential Tcl users, see what they're interested in, what their conceptions are, what they're using now, and so on - getting a feel for the market, in short.
- Tcl 9. Perl is blowing it, how will Tcl handle this transition. What new excitement will be offered? How will it answer the questions "Why upgrade?" and "What's new?" Tcl 9 will either be a major lever for Tcl and the future or it will be a major setback. Having it be vaporware will certainly guarantee that it is indeed a setback.
- Vote for Tcl in the Sourceforge 2008 community choice award.
- Add Tcl code examples to [2 ] alongside code examples from other languages. One candidate page is Hash-based message authentication code .
- Add Tcl code examples to sites such as Rosetta Code , where DKF has already done a good deal of fine work. Other sites include stackoverflow .
- Don't name your applications 'tk*'. Focus on what it does, so that people will take a look even if they aren't tk fans, or have preconceptions about projects that use it. However, do showcase the use of Tcl and Tcl-related technologies like starkits in your documentation and "About..." sections.
- Show how easy it is to build applications, and how, with a smaller amount of code, it is easier to maintain and extend. In most cases, the code will speak for itself. But an effort must be made to enlist closed source users to at least mention Tcl or Tk in the docs.
- Demonstrate cross-platform usability without modification. (RS) A cross-platform binary extension library would be a major plus here.
- Show how much smaller similar applications are when implemented in Tcl/Tk than in other languages. (escargo, 18 Aug 2003)
- Reach out to users of the Tk toolkit via bindings from other languages. Some success might be made "roping them in" from their other language if they are shown how Tcl can give them additional power over Tk and their applications.
- Reach out to users who do not like the editor/terminal combo. Some effort has been made, but a unified "reeducation" of longtime users must take place. Instead of "we do it this way", questions about GUI editors and IDEs must meet with meaningful answers. Again, this has gotten better, but I still see hints of a provincial attitude pop up in various forums I monitor.
- MSW: Show how many professional tools use tcl as their scripting plugin making it possible to write applications which either run in a standalone tclsh/wish or be loaded directly onto tools from which you can gain additional information for your own application.
- Continue learning about marketing (just don't turn into one of them!): http://software.ericsink.com/Marketing_for_Geeks.html
Discussion moved to Tcl Marketing discussion
Why Marketing Matters
When we talk about marketing, we don't mean used car advertising - trying to sell people junk they don't want or won't do the job for them. We mean increasing the appeal and perceptions of Tcl in order to effectively communicate its strengths to potential users. Some of this is just smoke and mirrors, and as such might be unappealing and counterintuitive to the programmers mind. But that marketing is unimportant could not be further from the truth.
In order to understand why it's important to try and sell something that's free, some concepts from the field of economics are useful. First and foremost, "demand side economies of scale", or "positive network externalities". What these terms mean, basically, is that for some products, they become more valuable the more people use them. The classic example is a cell phone. It's worth nothing if you're the only one to have one, and is much more valuable to you if all your friends have one. Programming languages are not valuable only because of the 'networks' they belong to, but it is something that's helpful. Think about being able to ask questions on comp.lang.tcl, or the chat room. Or be able to easily hire someone to work with your Tcl code, or conversely, easily find jobs where your Tcl skills are valuable. Think of the group of all users of a language as a pyramid, with Dr. Ousterhout, or Larry Wall, or Guido van Rossum at the top. Those guys are brilliant, but think of all the value provided by successive layers down the pyramid. All the libraries, the QA work, the books, the documentation, the user group meetings, and so on. All those things happen because the language is widely used.
But, you say, Tcl is widely used, why bother? Cobol and Fortran are still used well after their heyday, aren't they? Sure, that's true. Programming languages also have a lot of "lock-in". Switching costs are very expensive in some cases, meaning that once you've got a system up and running, redoing it is not going to be cheap. This is an incentive to keep maintaining and incrementally improving/upgrading existing systems, in whatever language they are written. Tcl is deployed widely enough that there are many existing users who will keep using it for years to come. However, if we only count on lock-in for Tcl users, we are looking at a long, steady decline. Sure it won't be gone tommorow, and there is money to be had riding it all the way down, but the size of the pie will continue to dwindle.
What we'd like to see, instead, is Tcl gaining in popularity, and being used for new projects. New projects in Tcl will create new users and developers, some of whom will create more valuable projects. In short, there is positive feedback involved, which means that the strong get stronger, and the weak get weaker. I would like to see Tcl on the 'getting stronger' side of that equation! To quote the "Information Rules" book, perceptions matter a lot in this space, or as a recent comp.lang.tcl poster says,
They need to know that they've "Made the Right Choice (TM)"
with regards to their choice of programming language. This goes for things like OO extensions too - the uncertainty of having to pick one extension over others leaves people with a nagging doubt that they may have made the wrong choice. Once again, the "marketing" is to have one clear choice and create positive perceptions regarding that choice. Everyone likes to feel that they've picked a winner.
And one payoff of this increase in users and developers is a larger marketplace. A larger marketplace has many benefits: increased opportunities for paid work, increased need for support services, the ability to sustain multiple vendors, and not least more publicity and success stories to feed the monster.
To bemoan the lack of these opportunities and payoffs is not productive; the productive course is to bring about the necessary conditions for them to exist. In an age where languages are a dime a dozen, and at a time when other languages are chipping away at Tcl's traditional niche areas, this work cannot be left to Activestate (no offense meant). The community must be mobilized as a whole as much as is possible and with as much united direction as is possible.
See the book Information Rules for more information on the economic aspects of high-tech: http://www.inforules.com/
I have also condensed some of the book's ideas into a paper that discusses the economics of programming languages in particular. It is available here: http://www.dedasys.com/articles/programming_language_economics.html
- Perl - still very popular, but dropping off in terms of new projects. Still have a very big library and system to access it - CPAN. There are lots of potential converts here, in terms of people who want GUIs, and a language that's simpler and cleaner. Even more converts are probably likely after the next version bump.
- PHP - Tcl isn't likely to make a dent in PHP's primary market, web programming. Even though we were there first with systems like AOLserver, PHP has taken off, and has really captured this market, along with Java for more complex applications. Tcl needs to watch out for PHP trying to break out of the web niche and expand into Tcl's territory - graphical apps and system scripting. Currently however, PHP scripts are more much work than writing the same in Python, Perl or Ruby.
- Pike [3 ] - WJP I'm surprised that people so rarely mention Pike in discussions of scripting languages. It's an attractive language, but it doesn't seem to be very widely used. My impression is that it is used primarily in Scandinavia and Germany. The syntax is more or less that of C, but it is strongly object-oriented and garbage-collected. Its closest relative is probably Java. The difference is that it has a much smaller footprint and that byte-compilation is faster. It is also arguably faster than Java. Like Java it has very good regular expression facilities, in some ways better than those of Tcl. The only graphics binding seems to be GTK+. Somebody really should make one for TK. I suspect it isn't likely to become a real competitor for Tcl because it is too low-level and complex. It's attraction is for someone like myself who is very familiar with C and for some purposes wants a language of the same sort but likes the idea of being able to cut development time and bugs.
For the novice programmer it is probably not that much easier to learn than C, and it doesn't have the high-level features that make Tcl attractive to more experienced programmers. (Truth in advertising requires me to reveal that the thing that I really like about Pike is that it is the only language I know of that has binary integer literals.)
- Python - Probably Tcl's main competition right now. Python is going very strongly, and is seen as a good choice for many people who want to use a scripting language - it may not be the best choice for any given problem, but it's usually 'good enough'. Some changes occurred to Python rather recently (2.4) which made it simpler to write short programs, giving it the possibility to compete with Ruby successfully. What areas is Python dominant in that we can catch-up to? What strengths does Tcl have that we can use to our advantage?
- Ruby - Still not all that popular compared with the other languages (a lot of development is done in Japan, and the documentation is mostly only Japanese there. You can read the source code, but it is an extra effort, taking some time so that translation is not that appealing because of extra costs), and probably more of a direct competitor to Python, with a clear advantage on the OOP aspect due to its inherent structure. But then again Ruby's default GUI is the Tcl/Tk toolkit, which makes it really easy to use it from within Ruby. (escargo 17 Jul 2005 - There has been a lot of buzz on the web recently about Ruby on Rails[6 ] and [5 ]. It's a web applications framework that supposedly gets the job done in much less code than a comparable Java stack. This comparison[4 ] between the two opens up the question of what would be the comparible
alternatives with Tcl. One aspect of Ruby that makes it work is the reflection and introspection that Ruby has. Certainly much the same should be possible with Tcl, but it's not a direction I have seen anybody trying to go.)
- Lua - Gaining ground amongst those who need a very small, simple language to embed in their apps. One way to fend off this challenge would be to modularize the Tcl core in order to make it more competitive in limited-resource environments. Tcl is more dynamic and more featureful than Lua, so for larger apps, Lua is not as competitive. (DKF: Lua often crops up as a scripting language for configuring computer games, where virtually everything is in C/C++ anyway.) Amongst the features that Lua is missing that many people expect of a scripting language is complex regular expressions. See the Lua page for more information.
- Java - Primarily a competitor in the GUI space because it claims to be "cross platform". The main Java GUI toolkit suffers from the same problem that Tk does, in that it doesn't integrate perfectly in all desktop environments (Mac OS X, Windows, one of Gnome or KDE). It is currently quite successful among company usage, possibly because of advertising.
- Visual Basic - Windows only, so we have a cross-platform advantage. Of course, a lot of people find the language quite distasteful. See its page for more details.
- Euphoria - available from http://www.rapideuphoria.com/
- Unix shell languages - Perhaps not competition as such, since these are not languages anyone would suggest for even a medium size project, but their non-interactive use is certainly a market that Tcl could cut into: cleaner syntax, nowhere near the same quoting hell. (RS: ...and cross-platformity, same script runs on Unix and Windows... At my work, there is a trend to convert shell scripts to Tcl scripts.)
IL 2005-07-19 Excellent summary of current language trends. Just wanted to add that, I just heard that Lua has been ported to the PSP. Tcl could use that kind of playful and modern visibility.
RLH Just having visibility would be nice. : )
Lectus It also seems there's a new trend of dropping native look 'n feel. For example, with the new Microsoft technology called WPF you create custom GUIs with colors you like, not following system's default. We have Tile now for using the native look 'n feel, but this makes Tk even more cool. It's very easy to create custom GUIs with Tk.