create new tag
, view all tags
So, if I was a new developer eager to work on something cool, how would I choose?

No. 1. Measure:

Measures TikiWiki TWiki
Developers 18 5
Activity Percentile (last week) 99.9621% 0%
Releases 5 in 6 months don't ask & don't talk about it, not even PM 101

Tiki 1.6 -Tau Ceti- RC1 released  lrargerich - 2003-04-09 16:43
Tiki 1.5 -Regulus- released       lrargerich - 2003-02-18 04:25
Tiki 1.5 -Regulus- RC2 released   lrargerich - 2003-02-13 11:30
Tiki 1.5 -Regulus- RC1 released   lrargerich - 2003-01-07 09:51
Tiki 1.4 -Mira- Released!         lrargerich - 2002-12-19 10:22
Tiki 1.3 -Pollux- Released        lrargerich - 2002-12-05 05:21
Tiki 1.2 -Antares- Released!      lrargerich - 2002-11-19 13:16
Tiki 1.1 -Capella-                lrargerich - 2002-11-01 10:56

In the minds of both users and developers this just has to be addressed. Perception really matters, it draws developers. Kill their ability to influence and they will get frustrated, their involvement will decrease and TWiki will die. Choose.

-- MartinCleaver - 11 Apr 2003

This has already been discussed elsewhere in Codev (where we found that the SF stats do not show the real picture of TWiki usage, e.g. 13,000 folks on the notficiation list, 120 on Codev notify, 50 on Plugins notify, around 3000 page changes per month, etc). There is also another perception. Other projects call production releases what we call alpha releases. How many alpha releases does TWiki have? Do folks in the corporate environment want to upgrade TWiki every week?

My question is why do some folks spend resources on dwelling on negative things, where in my view it would make more sense to spend time on spec and code contribution. Wouldn't that help the TWiki community continue to be on the leading edge?

-- PeterThoeny - 11 Apr 2003

I totally agree with Peter. TWiki releases are a long time in coming but:

  • They are solid
  • They are very well documented by open source standards
  • As it is open source anyone can do fixing for their local environment if they need to
  • The alpha release is always there and is usually fairly stable - TWiki.org is often upgraded to this

Also there are the plugins. The current Plugin mechanism has proved very popular and is where most releases are. Let's make sure that the Plugin API let's people change TWiki's behaviour in the way they require.

-- JohnTalintyre - 11 Apr 2003

I agree with Peter that Twiki is solid and has more users. But potential user investigating wikis cannot tell this from "impartial" statistics available to her.

It's not about facts, it's about perception. If Twiki looks stale, why should I waste my valuable time to research if it is true? My perception says it is stale, so I am not going to waste my time. Off the radar screen. Twiki could have the best code, but it will be only for insiders.

We can easily have more developers registered (including Plugins), weekly releases (accumulated patches) and digest of discussion. We can explain in project homepage where all discussions are. Just to beat them is statistics. Why is so hard to understand that we need to win minds of users before we have a chance to prove that Twiki is better? I know that it is additional work, but maybe there are enough contributors like me, which are not ready to contribute code (yet), but can work to improve Twiki rating?

Why it is so hard to see that perception is important? And in battle for mind, perception is the only thing what really matters?

-- PeterMasiar - 11 Apr 2003

For what it's worth, I agree that perception is important! (But, I am not one that has to be convinced.)

That said, I have two things to say:

  • The developers' time is precious -- if we can do something to improve the perception without taking any extra time from the developers,


  • if we don't do anything that is (or could be perceived of as) deceptive,

I'm all for it.

What exactly is being proposed — I mean what can I do?

Please be very specific if you want me to understand what you're proposing.

Should I register as a TWiki developer? I would not consider that deceptive because I do hope someday to help with TWiki development, but after I learn C to add keyboard macros to X, and learn C++ to add collapsible outlining to AbiWord (and move Wikilearn off Sourceforge) — so I'm a "future" developer.

Do we need to start a mailing list using Sourceforge? Not sure what that would do for us -- we (I think) use TWiki instead of a mail list for the most part.

-- RandyKramer - 11 Apr 2003

Where to start?

  1. We need to agreee that low rating is a problem and we want to do something about it.
  2. State in info page on SF that SF cannot rate our activity correctly, because main activity is made wiki-way in Twiki.
  3. we need to find out if there is somebody in Twiki community with idea how rating is calculated.
  4. I guess we can create a email list archive on SF and subscribe it to WebNotify changes
  5. Create downloadable archive and upload beta versions there when "reasonably stable".
  6. Start thinking seriously about improving usability, default templates and better, more intuitive out-of-box install. (and updates - CN)

BTW, Tiki is on 2nd place in SF activity as of today.

-- PeterMasiar - 12 Apr 2003

I added some comments at the bottom of CoreTeamNominationDiscussions that are appropiate to this topic.

Re: Tiki being in 2nd place in SF activity -- good for them!

-- RandyKramer - 12 Apr 2003

I think TWiki has a bigger problem than just the image conveyed by sourceforge: difficulty to upgrade. This prevents us to release often, which gives the impression of an active project. I knew I had to reserve 1 day of my time to upgrade my 4 production TWikis for the Feb 2003 release. In my opinion, that is way too much! Most people will not be commited enough to do it, and the installed base of TWikis will dwindle, and thus the number of useful plugins/enhancements, and it will die, something we do not want.

For instance, TWiki is still in use at my previous job: https://www-sop.inria.fr:444/wiki/bin/view but they still use the Sep 2001 version!!! The systems team there did not manage to upgrade to newer versions... This is very distressing.

On PeterMasiar points, I think we should do 2 & 5, as they are easy to do. (and 6 of course)

PS: I find the TWiki.org too slow for confortable use. This - I think due to not using modperl ? - and the absence of a "save without preview" makes editing a bit cumbersome.

-- ColasNahaboo - 12 Apr 2003

The upgrade issue is a real one even for people with pretty good TWiki/Perl skills - I had to spend half to one day upgrading TWiki a while back, due mainly to merging new topics and so on. It's quite a hard problem to solve, with various possible solutions of course. FreeBSD has a tool that lets you merge locally customised config files with a new release's files, which may be worth investigating. Keeping local customisations separate somehow would be great, through some sort of search path for config files. There's also the issue of locally customised scripts, though the plugins architecture does help a great deal where it's applicable.

I am not quite as pessimistic about impact of people not upgrading - they are still running TWiki, and there are enough new users that the new code gets tested - but it is important to address this issue in next year or so to get people onto more mainstream code etc. Perhaps if there were more frequent releases, someone would start working on the upgrade issue.

-- RichardDonkin - 13 Apr 2003

Just fixed one of my "grammos" above (s/is/are/).

-- RandyKramer - 13 Apr 2003

The previous Codev discussion and the statistics PeterThoeny mentioned are in the topic TikiWiki.

The key reason that Tiki ranks so high is that it uses the SF services extensively so almost every change is reflected, while TWiki is a minimalist, only using the services it actually needs outside of itself: cvs, cvs mailing list, and web hosting. The available services are: cvs, mailinglist, bug tracker, feature request tracker, support request tracker, patches, release downloads, public forums, doc manager, news releases, and finally website hosting. (I may have missed something)

It doesn't make any sense for TWiki to move services it does for itself to SF in order to improve a rating based on a flawed system. I speculate Tiki uses so many SF services because they started on SF, it's their hatchery, while TWiki moved there. Sprung from the head of Zeus fully formed, so to speak. TWiki could move to the entire project to a new host next month with relatively little pain and most of the community would never notice.

I'd admire Tiki for it's absolutely ferocious development pace. New features seem to be added every other day. But as an administrator I would be nervous about using a this kind of project in any real way. Things change too fast to track. So one the one hand TWiki is too slow (lacking the changes I want to see) and on the other it is just fast enough (not too many changes I don't care about).

> _... it would make more sense to spend time on spec and code contribution. Wouldn't that help the TWiki community continue to be on the leading edge?_

Yes it would, but most of the people making noise about this, like me, can't spec and can't code. If we can't inspire an existing twiki developer to grab our ideas and run with them the next best hope is to broaden the pool of developers and hope somebody bites.

> It's not about facts, it's about perception.

No, it's about facts and perception, and there should be no gap betwixt the two. If I have to choose one, I'll take the facts please. I have enough bad tastes in my mouth from products which are thick on perception and lean on substance already thank you very much.

To bring this back to the subject at hand: I third the suggestions to 1) add a mention re: the SF stats problem to the SF project page, 2) make betas downloadable, 3) make upgrades easier. If I have to choose one, it'd be better upgrades.

Before signing off I'll add one more data point to the graph: there are two twiki projects being hosted on source forge. Raise the SF-visible activity of one and I'll wager both are lifted.

-- MattWilkie - 14 Apr 2003

Edit | Attach | Watch | Print version | History: r11 < r10 < r9 < r8 < r7 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r11 - 2003-04-14 - MattWilkie
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.