Tags:
create new tag
, view all tags
Why do I have to register before I am allowed to download final releases of Twiki? (Almost) no other open source project makes me do this. This is an unreasonable restriction.

Definitely a frequently asked question. This topic has been created so the discussion can all happen in one place. When you see this thread crop up on other topics please direct it over this way.

Note that TWikiBetaReleases can now be downloaded using the TWikiGuest user, password guest, i.e. without registering.


For the record, the answer is:

This is a controversial point because it is not typical in the open souce community.

Please let me try to make my point again: There [are] lots of internet communities using xyzScreenNames, and with that, colorful language hidden behind anonymity. The TWiki community has a personal touch - by design. Personally I like to see that our community gets to know each other by their real names. Frankly, I am not interested in getting Beta testers who do not fit into this friendly environment. The Beta URL is communicated by e-mail (usually within 12 hours) with an invitation to join the developers team. Then, a permament download URL is communicated if a users joins the team. This is pretty effective in recruiting nice folks, the rest choses to go elsewhere - by design, smile

Here is another point: TWiki's mission is to be "a leading-edge, web-based collaboration platform targeting the corporate intranet world." In this environment it is not unusual to fill out a form to get or register software.

-- PeterThoeny - 06 Jan 2003

-- MattWilkie - 15 Jan 2003

Discussion


(moved here from TWikiBetaReleaseDiscussions)

To add some feedback from people I have talked to online and in person: at least a couple of them saw the registration form for downloads and immediately gave up. One of them did not even realise that TWiki was GPLed - he just assumed that any software that required registration was at least somewhat proprietary, and since he wanted an OpenSource Wiki, he went with UseModWiki instead. This applies to TWikiProductionRelease but the issues are similar when downloading betas.

OpenSource projects very rarely use this sort of registration form, although the data collected is quite interesting. Now that TWiki has a substantial user base, perhaps it is time to consider either dropping registration, or making it optional? This would help prevent the perception that TWiki is not OpenSource, due to this registration form (which many people clearly don't read in detail). A prominent link to the TWikiInstallations form might be good to get some details from those who don't submit any info on an optional registration form.

VNC is one open source project that does use optional registration - they ask you to complete the form but it is clear that you could just hit the Submit button and still get a download URL. Here's their original form and current form - one spin-off project has a no-forms download page, which can obviously happen with any GPLed project (though I think the fork was to add new compression features).

Particularly since people get so much spam these days, they are quite sensitive to entering a valid email address, which is another reason why registration tends to put people off. I think the VNC download model is quite reasonable - it says that it is GPLed quite prominently and then asks people to provide some info, but without requiring this.

Anything that leads to a beta tester wasting an hour of their time is worth avoiding IMO! People who are willing to test betas and alphas are thin enough on the ground as it is smile

-- RichardDonkin - 27 Nov 2002

Peter, I appreciate the belated welcome message for the beta release you sent me this morning.

Why not just set up Apache user and group rights on the .zip files? This way, an existing TWiki user could submit a form to join the Beta (or Alpha) team and all you'd have to do is update the group list with the userid of the new tester. Then, you could publish the urls everywhere without too much concern. (Better yet, fix the bullet holes in TWiki's security mechanism, then upload the .zip file as an attachment to this topic!)

As far as the production release is concerned, I agree with RichardDonkin. If it's OpenSource, you shouldn't worry so much about collecting email addresses. File download statistics can be determined from the server logs or other added tracking software.

-- TomKagan - 27 Nov 2002

I agree. And given it is now eaasy to download TWikiAlphaReleases as zips, why not extend the mechanism to TWikiBetaReleases?

New people are likely to want the release version and therefore register. Only your dedicated hacks are going to be interested firstly in betas and only eventually alphas.

-- MartinCleaver - 14 Dec 2002

I've just recently started experimenting with TWiki, and I was a bit surprised to see a registration form pop up when I downloaded it for the first time. Anyway, I would second the motion to remove the registration from the download page.

As to why a new user might want to download the beta, I'm in exactly that situation. I want to use the beta so that when the real release comes out (which doesn't sound like it's too far from now) the upgrade path will be as easy as possible. I've already run across a few plugins and skins that assume a slightly different directory layout than the most recent full release. (By the way, I've already got the beta from Peter by re-registering, so it's not exactly impossible.)

-- DaleHagglund - 15 Dec 2002

True, but betas only because 1) our betas are somewhat more stable than they might be (undoubtedly a good thing) and 2) our releases are somewhat more infrequent than they might be (perhaps a less good thing). If we released more often (i.e. the last TWikiProductionRelease was say 3 months old rather than over a year old), new people would be more likely to want only a production release.

-- MartinCleaver - 16 Dec 2002

Well, I would at least like to see the distribution of the beta URL distribution be automated. I'm pretty sure I chose to download the beta version on the request page, but the e-mail I got in response only had links to the production version. This leads me to guess that a real person has to go through the submissions and e-mail all the putative new beta-testers...what a waste of time, both for the person who has to send out the e-mails, and for all the people who have to sit around and wait for them before they can access the beta.

As far as eliminating or optionalizing the registration page - go for it! I can't believe the data you get out of that page could possibly be as useful as all the users you'd gain by not requiring it of people. If it weren't pretty sure I'd like and use this wiki a priori, I know I'd just go find another wiki package rather than wrestling with a registration page and my e-mail client just to get a URL so I could try the silly thing out. What a pain!

-- WalterMundt - 06 Jan 2003

This is a controversial point because it is not typical in the open souce community.

Please let me try to make my point again: There lots of internet communities using xyzScreenNames, and with that colorful language hidden behind anonymity. The TWiki community has a personal touch - by design. Personally I like to see that our community gets to know each other by their real names. Frankly, I am not interested in getting Beta testers who do not fit into this friendly environment. The Beta URL is communicated by e-mail (usually within 12 hours) with an invitation to join the developers team. Then, a permament download URL is communicated if a users joins the team. This is pretty effective in recruiting nice folks, the rest choses to go elsewhere - by design smile

Here is another point: TWiki's mission is to be "a leading-edge, web-based collaboration platform targeting the corporate intranet world." In this environment it is not unusual to fill out a form to get or register software.

-- PeterThoeny - 06 Jan 2003

TWiki "the software" download does not need to have anything with the content contributed on TWiki.org "the Wiki" so I am not convinced with either of those arguments personally. -- ManpreetSingh 16 Jan 2003


I think that user registration and beta downloads are separate issues. It's a good idea to have everyone register with their real names, which helps contribute to the community feeling. However, in Internet terms, 12 hours is a long time to wait for someone who wants to test the latest beta - since there is quite a big gap between production releases, and betas are quite stable, the beta is a highly usable release. So there will probably be 'real beta testers', who will probably make themselves known anyway through useful bug reports/fixes and features, and 'beta users', whose main interest is a release which is close to a future production release.

I know that some people are put off using TWiki by the need to register before downloading, and if even one of those could have contributed useful bug fixes and features, it is a great shame. There is quite an overlap between the corporate and open source worlds, since many corporate users also download a lot of open source software on Linux/Unix or Windows. Now that everyone gets so much spam, there is a great aversion to registering before trying software, and the registration creates the perception that TWiki is not open source (see example above of someone who went for UseModWiki for exactly this reason). There are very few true OpenSource packages that request registration to download any version, and the only one I can think of (VNC, http://www.realvnc.com) makes this optional.

A reasonable compromise might be to make registration optional (for beta/production), but request it so we can know more about the user/developer base; and to generate the URL for download as a result of submitting the form. This would avoid a long wait for a beta download URL through email.

-- RichardDonkin - 06 Jan 2003

(moved here from TWikiBetaReleaseDiscussions)


There was a discussion elsewhere (please add links) about current registration policy perceived as user-unfriendly. Hardly any other open-source project has that. IMHO if we will invite users to register (and explain to them that their feedback is valued and they are invited into a community) and give them a choice to download anonymously, we will lose nothing and may gain some privacy-concerned users - which may register later anyway. This includes privacy-concerned business users.

And also, "a download (of Twiki) a day keeps TikiWiki at bay" policy might give Twiki a position among wikis which it deserves. wink

-- PeterMasiar - 15 Jan 2003 (moved here from TikiWiki)


When I first looked at TWiki a couple of years ago I too was put off by the registration requirement and didn't register for awhile. Over the course of time as I observed the twiki.org community operate and read about the twiki feature set, and the more I heard in other places, the less antagonistic I felt about the registration policy until eventually I registered, (obviously).

Since then I've revised my opinion. It is readily seen that PeterThoeny feels strongly about keeping the "users must register to get beta/production releases" restriction, and so far that policy has not been shown wrong -- witness the extremely high signal-to-noise ratio on twiki.org. I don't think I know of another online community with a comparable ratio.

So, while I initially thought differently, I support the registration policy.

-- MattWilkie - 16 Jan 2003

There are many, many reasons to change the policy as it stands now. What to change it to is the question. I also strongly believe that from what I know there are ways to address ALL the concerns and goals of the current policy. However we need a volunteer who will try to be as impartial as possible to review this discussion and take the time to clearly summarize. Without a summary and weighting the relevant issues and seperating issues that can be somewhat isolated I predict little forward movement will take place.

-- GrantBow - 16 Jan 2003

As work progresses on things like the TWikiOnDebian package, and similar externally available releases the usefullness of 'registration to download' will be significantly diluted. The TWiki comunity is strong enough to not need download counts to gain feedback, though registration to post and be a part of the community is a very reasonable, useful idea (quite seperate from access to the OpenSource).

I have given CDs of the twiki to friends, used the anonymous cvs repository and now the debian package to get access to a release without registering.

I think that we should release packages (not necessarily the alpha / beta releases) without registration. It appears quite strange that such a lively, active and successful project has still registered no relases on sourceforge.

-- SvenDowideit - 16 Jan 2003

There is a difference between registering to use TWiki.org, which is a big reason for a good signal/noise ratio, and registering to use the TWiki software, which really just slows down people who want to evaluate it, and in some cases puts them off completely.

Sven's point is interesting - anyone who wants to burn CDs, or put up a server hosting downloadable copies of TWiki software is completely within their rights, since TWiki is GPLed in any case.

One thing that would help is a deadline for a decision, I think - how about Feb 15th? I would like to see some comments by PeterThoeny, as he seems to be a key person supporting the current policy. Once we have had some more discussion, maybe a NoRegisterDownloadVoting page would be helpful?

-- RichardDonkin - 30 Jan 2003

While that date does seem very close, especially with a new release and the SourceForge issues a quick decision to make some kind of change would be beneficial. One thing at a time. I just talked to Peter and I'm pretty sure he's not thinking about GMT, but GMT-8 here in California...

-- GrantBow - 01 Feb 2003


Issue Pro Download Registration Argument Con Download Registration Argument
Gather statistics Better understanding of usage its not a valid measurment of usage, nor of interest. gives no facts
Gather valuable comments from casual users Better understanding of usage  
Notification service for new versions (optional) Possible Not possible (a majordomo signup is also a registration
Registration of software is not unusual for TWikiMission users N/A, common practice for target audicence it's still bad
"personal touch" of TWiki community prevents undesirables prevents usage and is a separate issue not directly related to download. This is related to RegisterForEdit, not RegisterForDownload.
high quality beta testers, effective recruiting good quality developers not a related issue to download itself. Any restriction in movement of software restricts POTENTIAL developer pool.
TWiki.org account   our lack of releases (in the proper sourceforge way) leads to this project looking dead especially when compared to tiki ... or any other project that follows the sourceforge model of releases and development TWiki.org account is not related to download policy
Other distribution mediums   deb now and rpm soon to assist TWikiMission
Download time delay less then a minute for production release; small for Beta release, few minutes if Peter is online (and he is online a lot) up to 12 hours discourages many, gives strong impression of non Open Source project, manual intervention required taking up PeterThoeny's valuable time.
SourceForge resources Minimal increase: 867M total vs. 37M zip files our policy (using TWiki web storage instead of sf.net's download mirrored facility) is causing disk space and bandwidth issues that they have asked us to address

I don't understand the last point, how is the must register policy causing bandwitdh issues? If anything I would expect it to decrease bandwidth use.

-- MattWilkie - 07 Feb 2003

Re the SourceForge resources issue - SF have said to the CoreTeam via email that we should be using the download mirror network for downloads. This reduces SF's download bandwidth, since the mirrors are third party sites - no doubt the no. of downloads would be higher, but the impact on SF would be reduced.

Much of the bandwidth issue is non-download-related, i.e. normal TWiki.org usage, but moving downloads over to the mirror network would show that the TWiki project is willing to do things 'the SF way'.

-- RichardDonkin - 08 Feb 2003

moving downloads over to the mirror network would show that the TWiki project is willing to do things 'the SF way' ...

  • and will make Twiki 'downloadable for free' like other GPL projects
  • and will show on SF stats page Twiki is alive - huge argument IMHO

We can invite potential user dowloading Twiki to visit our community, but why force him/her to do it our way before showing any potential gains?

Requiring registration before enabling dowload is just another issue what I do not understand: why is done in this stubborn Twiki way? Why not to do it as all other GPL projects do?

-- PeterMasiar - 08 Feb 2003

Lack of movement regarding this issue is clearly indicative to me of some current opinions regarding NoRegisterDownload changes.

-- GrantBow - 24 Feb 2003

OK, here are some facts: In the last 7 days we had 347 source code requests. Content of the comment field:

Tone Percentage Actual Examples
N/A - empty 88%  
smile - positive 4% - "This is the third twiki I've set up. Great tool. Thanks Peter and all."
- "cant wait to try it"
- "We're looking for opensource intranet/groupware for our Business Technology class intranet. We're tired of the one webmaster sign of a out-of-date intranet and your software looks like a good resolution. Thanks, and keep up the good work. Viva la GPL!"
- "Love it!"
indifferent - neutral 6% - "I am a consultant working in the field of development/ humanitarian aid. I want to..."
- "Looking at it for developer collaboration in requirements capture (rather than being constrained within Rational Requisite Pro) and object-oriented analysis & design"
- "Another group within [company name] has installed a Wiki and found it useful. I am looking at installing a similar system for my new group, and thought I'd check out Twiki."
frown - negative 2% - "not content with newest version, as problems occurred after update"
- "I'm happy to support your efforts, but please get rid of these ridiculous form!"
- "Wouldn't it be nice if I didn't have to fill out this form?"
Total: 100%  

Most comments are positive or neutral. Of those 2% negative comments: some are not download related; some are friendly requests to remove the form and some are colorful. Almost all of the negative remarks towards the form are from non-corporate users, e.g. not from the TWikiMission user base.

A form for software registration is very common in the corporate world. Granted, it is highly unusual for GPLed software, but why sould I do "what all the others do" if I believe there is a value in continuing the current policy of download form and developer selection process?

  • Notification service for new versions
  • Ability to understand usage patterns
  • Get valuable feedback from casual users - users who do not take the time to contribute in Codev
  • Maintain a very high signal-to-noise ratio (anybody knows a publicly available system where anyone can register with a higher ratio?)

Some other points:

  • Growth is good, controlled growth is better.
  • I do take the time to read every comment and reply to some. This is time well spent.
  • TWiki had this policy from the beginning. (compare with noise complaint by person who moved next to an airport -- who was there first?)
  • Exception for download policy already exists with Debian distribution (and others to come) which have a friendly request to provide feedback in a web form.

This is not to say that this policy is set in stone. A policy should evolve over time, driven by compelling arguments.

-- PeterThoeny - 10 Mar 2003

Of course, the registration form doesn't capture comments from those who give up and download another Wiki without a registration form, so I don't think that's the best place to draw data from on this issue - it will tend to underestimate dissatisfaction with the current policy. If 2% (out of 12% who commented) are not happy with the form, there could be another 10% or even 50% who didn't bother - we just don't know.

I don't have a problem with optional registration, it's just making it mandatory that causes complaints - getting the data is possible either way. There is also lots of software used in the corporate world that doesn't require registration, e.g. Apache, Perl, Python, etc - almost all registration required software is in fact commercial.

This is something that should be agreed by consensus, I think, particularly among the CoreTeam. Consensus and appropriate compromises by the CoreTeam have proven quite important in the codebase for TWiki and should really apply to policies.

-- RichardDonkin - 10 Mar 2003

This issue remains unaddressed. I feel the current policy is onerous, unrealistic and damaging long term. I feel SOMETHING other than the current practice needs to be worked out soon.

-- GrantBow - 02 Apr 2003

I must also say that the current form is totally counter-productive and irrelevant. (T)Wiki usage spreads mostly by word of mouth, and when I advise people to try TWiki, most of them come back and tell me "can you just give me the version, I do not want to fill a form just to try things". And I give it to them.

Registration is useful, but should be done optionally, and after installation and some use. E.g., use an "announce of new versions" mailing list that people can (un)subscribe at any time, just as I do for KoalaSkin.

Also, I am the only one to give fake email adresses (via http://spamgourmet.com) and ID when I am asked to fill a download form?

PS: I use Debian, but I never saw this download form... I just grab the ISOs on FTP mirrrors...

-- ColasNahaboo - 04 Apr 2003

My view concurs with the 'don't force pre-registeration' for to do so is utterly offputting.

Registration should be optional but if mandatory must be after they have done the work to install it. That way people have invested the time.

With so many high-contributing members of the TWiki community so against preregistration, failure to budge on this issue amazes me. Furthermore, it gives me no faith that developers voices will be heard and taken account of on other issues. This topic being unresolved and highly visible is detrimental to the furtherment of the TWiki development community. Who would want to join the CoreTeam when they know that Peter will override any decision?

Peter might have put in most of the work in the past, but for TWiki to grow he has to move to encourage and faciliate the incorporation of other developers. Stubborness on this issue does not help.

-- MartinCleaver - 04 Apr 2003

There's nothing wrong with the registration process per se; it's much better than (almost) any other registration out there. The problem is that any registration process for "free software" is going to arous suspicion. People are not going to understand that TWiki's is the only good one, they're going to see it and equate it with other sites that are evil. I'm sure my first reaction to it was about the same as many other people would have: What's this? I thought this was GPL'd? Where's the direct download link? It's not optional? What's this guy going to do with my e-mail address? Do I trust him? Maybe this program isn't worth it.

Once we've gone through it, and we know what TWiki is and what it's about, and begin to understand that there is a real collaborative open-source development style on the other side of the gate, it's not so bothersome anymore. But I do agree that it probably turns a number of people away. For purely selfish reasons (I already have four of them installed and don't want to have to start over with something new) I want to see TWiki as the dominant, best, most well developed and maintained Wiki system. That's probably the position it's in right now, but Wikis are still on the cusp of gaining critical mindshare, and another project could easily come along, grab everyone's attention, and leave us in the dust. The register-to-download system can only help that to happen.

-- ChristopherMasto - 04 Apr 2003

On re-reading my wording above it seems that what I said can be construed as an attack on Peter. I'd like to say that this is not the case, I was just summarising and extrapolating the frustration that I sense when reading through this page. I apologise to Peter and to anyone who thinks I went too far.

-- MartinCleaver - 06 Apr 2003

Sven's comment got me thinking. He said:

  • I have given CDs of the twiki to friends, used the anonymous cvs repository and now the debian package to get access to a release without registering.

Which made me think: _Of course, the GPL states:

  1. You may copy and distribute verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and give any other recipients of the Program a copy of this License along with the Program.

Frankly, I would be surprised if the latest version of TWiki wasn't already available on a multitude of FTP servers. Unless I mis-understand the terms of the licence, any person wishing to would be perfectly within their rights to set up a FTP project or SourceForge project soley to distribute it.

I'm surprised that no-one has done this already. As such, this would circumvent the registration process.

I therefore think that it is dangerous that the registration process occurs before installation, don't you?

-- MartinCleaver - 10 Apr 2003

"I therefore think that it is dangerous that the registration process occurs before installation, don't you?"

What danger are you referring to:

  • stats will be misleading because of people that register, download, but never install
  • the impetus (that you mention above) toward putting TWiki on an FTP site that registration causes
  • something else??

-- RandyKramer - 10 Apr 2003

Re: noise complaint by person who moved next to an airport

I remember I almost rejected Twiki because I did not want to register. I wonder how many other users rejected it because of that. These will not be in our stats - they will be happily using other wikis.

I expected Twiki is a GPL project and will behave as other GPL projects. I spent considerable time tinkering with Twiki (of course not comparable with CoreTeam time), and really like Twiki to grow, and am working in time I have and using skills I have to improve Twiki's usability. At least as I understand usability. And as other experts on web usability (like J.Nielsen from http://www.useit.com) understands it, as I am learning from them.

Because we know other wikis are around, and there is competition for market share, and for mind share. I do not want Twiki get betamaxed. Some will care if Twiki has better features, but if other wiki will have much more developers, they will add more features. And will leave Twiki in the dust.

We already know there is another wiki, Tiki-Wiki, on SourceForge, and is more popular than TWiki. Currently number 5 as most popular project on SF, visible at every SF page! At least we need to mention is single paragraph allotted, that Twiki is stable and not stale - all activity is done wiki-style, not in SF forums. Without this, for casual visitor 0% activity is same as stale GPL project, and there is a lot of them.

We are fighting for a mind share. We might feel good about what features we are adding, but from outside Twiki might look as stale. Doesn't is scare you? The only payoff Twiki developers have is to be member of the winning team. I want to be a part of the winning team, too.

My goal is Twiki to succeed and become the best, most powerfull and maybe most used Twiki. And then being able to say: this little feature was my suggestion. wink

I know I am not contributing code so my opinion does not count much in traditional hacker communities. But I was thinking maybe in a community for a Twiki as a tool to aid collaboration, I could contribute by improving usability for non-hackers. I might be wrong, of course. frown

-- PeterMasiar - 10 Apr 2003

  1. CgiWiki does not require registration
  2. TWiki's registration mechanism is ineffective as it does not record how many installations are created, only the number of times it is downloaded. I for one install it many times using the same install zip file. (ASIDE: I then patch it hundreds of times in each year to keep up with fixes, with each patch making me less and less keen to install the new version for fear of losing a unique customisation).

My installation of CgiWiki was far less painful. I just get Cpan to work (my hosting provider provides it), and then instruct them 'please update'. As much as it is an bother to ask this of the hosting provider this is nothing compared to the day or so I need for hand-patching TWiki.

  • CGI-Wiki-0.38 - 17 May 2003
  • CGI-Wiki-0.32 - 02 May 2003 (and five releases in the 15 days between)

To counter Peter's figures: Is the market for Wiki's is increasing faster than our number of installations. Ie. is TWiki losing market share?

-- MartinCleaver - 21 May 2003

See TWikiBetaRelease. Not quite a NoRegisterDownload, but I suspect acceptable to significantly more people. (The password being required might be a mistake - though I'm 50:50 on that - it might not be. I've not checked if TWikiGuest/guest works. Either way having the location obvious is positive, and makes the step about as "onorous" as username/password being required for FTP downloads.)

-- MS - 19 Dec 2003

Just realised that NoRegisterDownload is now effectively implemented, for TWikiBetaReleases anyway, since TWikiguest/guest works fine. A good thing in my view!

-- RichardDonkin - 30 Oct 2004

Edit | Attach | Watch | Print version | History: r28 < r27 < r26 < r25 < r24 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r28 - 2004-10-30 - RichardDonkin
 
  • 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-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.