Update: klik is going GPL (dual license like qt), see next page

I have opened this thread to discuss the future of klik. Thanks to all of you who share your ideas on how klik can be made a killer app.

Before we start discussion, let me share some of my personal views about klik:

* Knoppix (or any other system) is the "base", klik is for supplying (relatively small) add-ons.
This means that klik is not designed as a "package manager" that could or should replace apt. Instead, klik is designed to be the easiest way for the user to add, let's say, RealPlayer (which will not be a part of debian anytime soon). Klik is designed for the dialup user who just wants to download the minimum of what he really needs instead of MBs of apt package descriptions. This also means that each klik recipe will be built for a specific version of Knoppix (or any other system) and is unlikely to run on (very) others. klik shifts the task of "package management" away from the user towards the developer of the klik recipe.

* Each klik recipe installs one "self-contained" application (or set of apps).
This means there will never be "dependencies" between klik packages. klik doesn't *want* to have dependencies. The user should always be free to delete an AppFolder without having to fear that this could break anything else. klik is designed for people to try out many new apps just for fun and then decide whether to keep them or not. In cases where several apps share many common parts (e. g. libraries), these packages should be built into one klik recipe (e. g. mplayer, mencoder, kplayer, kmplayer, kmediagrab could well be in *one* klik recipe).

* klik recipes use server-side PHP includes.
This makes it easy to upgrade code that is common to many klik recipes. Ideally, we would have just one "generic" klik code for a certain type of app (e. g. KDE, Gnome, Wine, Konsole apps). Then making each recipe would be quite easy, as it is today already for KDE apps.

* klik should use, but not require deb meta information.
deb packages contain a lot of useful information (e. g. menu entries, postinstall scripts) that could be used by the klik recipes. However, klik should never be dependent on the deb format, but instead also allow for other packages (e. g. RPMs) to be used. Sometimes, there are no deb packages for a certain app which nonetheless runs fine in Knoppix.

* klik should allow the easy integration of non-free apps.
It is a matter of fact that many users want an easy way to add non-free apps to their desktops. klik should allow for that to happen in a legitimate way. Since klik scripts can download packages from the commercial vendors' servers directly, licensing should not be a problem. klik recipes don't "redistribute" software, they simply tell the client where to obtain and how to unpack packages. (*If* this is in contrast to debian philosophy, klik cannot be integrated into debian. Sorry.)

* klik should have *one* central store that is open to all.
What is the greatest pro of sites such as kde-apps.org? Well, it is that they show all the KDE apps in *one* place. I go there, and I know what exists. All sorted in convenient ways. Wouldn't it be even greater if there was a place like kde-apps where I knew each app I see could be installed on *my* system hassle-free with just one klik? Of course this would be much nicer than having to seek for apps in many different places as it is today. Because of that, we should try our best not to have multiple klik stores but *one* store that would have to be open for all. "Open" means that everyone can use and upload klik recipes BUT there must be some sort of quality control built in. Since klik recipes run on the user's machine, they are potentially dangerous. So I envision a klik store that works similar to shalshdot: Everyone can post klik recipes (and improvements) like in a web forum, but they become klikable only after a moderator has "modded them up".

* The klik store should have a system for users to report their success on different (standardized) systems in an easy way. After each klik installation, there could be a screen in the klik client that asks "worked" or "did not work". THe klik client could submit this information, together with the information about the system it is running on, to the klik store's database. That way, people could easily see "runs with Knoppix 3.3 19-11-2003".

* klik recipes could be autogenerated on the server.
Using apt-get server-side, it should even be possible to auto-generate klik recipes server-side for at least some classes of apps, ot at least minimizing the klik recipe developer's effort through "wizards". It should always be possible, however, to hand-write recipes.

* the klik client source should not be open to everyone.
Otherwise, generations of hackers and dialer programmers could use slightly modified versions of the klik client to do their evil thing. I do not want to help them by providing them with the code of the klik client. No question, every hacker could write a klik client like program on their own, but giving it to them openly would allow every "script kid" to do evil things with it. Therefore, I suggest making everything GPL except for the klik client, which would be released as closed-source freeware. People with a long tradition in open source development would get the source code for inspection, but not the general public. Again, this is just to prevent KDE from becoming a platform for dialers and stuff.

* klik allows for easy "software URLs".
What can you remember better - klik:/RealPlayer8 or http://www.mygreatserver.com/downloa...ation/8/rp.gz?

These are my personal thoughts. They are not the only way to to klik, but they are how I envisioned klik when I created it. Some people think klik has the potential to make a huge impact for Linux on the desktop. Sure enough, I am unable to actually build all of this on my own. The future of klik is really what you - the GNU/Linux, debian, KDE, Knoppix, ... community - make of it. I will sure do what I can, but I cannot do it all alone.[/b]