Teach someone to fish and you feed them for a lifetime.
Add that knowledge to a wiki
And countless people will be able to learn on their own
And share their knowledgeAnd many more will feed their families
Then, more wiki knowledge will be added to deal with Overfishing
Tiki is my first experience (other than as a user) in an open Source project. This has been a great ride so far. Here are my ideas on the project.
I don't blog (I prefer wiki page and mailing lists) so if you want to know what I am thinking, subscribe to the Tiki Dev Mailing List.
The stuff below is pretty outdated by now. I suggest you check out:
- 2009-02-08: Video Presentation Fosdem 2009
- 2008-06-24: I started a little analysis of the CMS Landscape
- State of Tiki: Overview of the project/community
- Why Wiki Syntax is Important
- Business Models
- FLOSS Web Application with the most built-in features
- Coping with Complexity
Table of contents
- Tiki Vision (What?)
- Project Management (How?)
- What has been accomplished (What happened)
- Now what?
- Eating our own dogfood, Finish part 1 (Documentation)
- Eating our own dogfood, part 2 (project management/groupware)
- Other missing features of a web operating system:
- More partnerships
- Tiki companies
- Tiki visibility to the next level
- Pitfalls (What could go wrong?)
Each Tiki contributor will have his/her own vision. The cumulative ideas & efforts of all contributors have made Tiki a fabulous project. And Tiki is still young!
I would like Tiki to become a "Web operating system" ie web-based integrated virtual desktop. Basically, I want to use Tiki via a web browser for all general purpose projects and to be an alternative to the classic install OS/install software on one computer.
Install Tiki (locally or on a server) and you can, through a web-based interface activate and deactivate a large number of features. With users/groups/permissions, you can have an unlimited number of users on one Tiki installation, each accessing only the features & data they need.
I would like to be able to use Tiki as a personal knowledge base, run a small to medium organization (business, not-for-profit, education, etc) or even a small country! (ex.: http://www.maps.gov.ck/) Thousands of people doing all the stuff they need via their favorite web browser. In a large deployment scenario, thin clients could be used for 90% of the users. Classic operating systems and software installation/upgrades would only be for users with special needs (graphic artists, video editing, etc)
Tiki has the feature-set to power 90% of websites in the World. (Let's face it, most sites are pretty simple!). Please see: Use Cases
My preference is to keep as much as possible of Tiki in PHP and using any database so that it may be useable in many scenarios, including shared hosting accounts. Tiki should continue to support all browsers. Java applets are acceptable. And you should be able get a backup and run your Tiki on a USB key. Say for a portable knowledge base, for example.
As of Tiki5, Tiki globally corresponds to my original goal of a Web Operating System. It will have taken 7 years, instead of the 5 I thought it would. And the work continues on to
Tiki Suite. WikiSuite.org
Luis Argerich started the Tiki project in October 2002. Tiki caught my attention and was growing very quickly (7 releases in 10 weeks!). Unfortunately, Luis is currently not very active at the moment. However, he acts as a "senior adviser".
I will take the credit (and/or the blame!) for Tiki's "recruit early, recruit often" strategy.
As Luis was becoming less & less available, I started (with Luis's accord) giving CVS write access to anybody who submitted a patch or who hinted they would.
My focus is to get smart & dedicated people collaborating to solve a problem.
I want everyone to take "ownership" of the project and contribute as much as they can. Be it with docs, translations, ideas, testing or code. With CVS's inherent version history, I figured the benefits clearly outweighed the risks.
I think the wiki aspect and personal UserPages of Tiki has helped quite a bit for people to use and to get involved in the Tiki CMS/Groupware Project.
Completely open source, I would like each feature to be "adopted" by one or more devs. These devs work together to make sure shared/transversal features & the core do the job correctly. They will make sure the whole is much more than the sum of its parts. These devs will be able to focus on making their feature at least as good as any "standalone" application.
I think we should try to keep things centralized.
- Everyone working directly in CVS instead of scouring the net for patches.
- **.tiki.org for localized sites with unified login (although permissions can be different on each site).
Tiki Wiki CMS Groupware is, as far as I know, the open source Web application which offers the most features "out of the box". (Some others offer more but only via 3rd party module installation).
All this in one nice integrated package with consistent look & feel, site-wide stats & search, and single sign on.
- Tiki runs anywhere where PHP does
and (with Tiki1.8ADOdb) with all the major databases.only MySQL
- Tiki users can use all modern web browsers
- Tiki supports WAP/VoiceXML for cell phone/PDA accessibility
- Tiki is international (
Starting with version 1.7, thanks to Al Brown and mose, we started using Tiki to run tiki.org This has had a profound positive effect on Tiki development. Please see: DogFood
As we add new features, we usually debate 3rd party code integration vs building our own. Where possible, we have chosen to reuse code & libraries. Please see TikiPartner and "More partnerships" below for examples.
A few months ago, I wrote:
We now have sufficient eyeballs.
- 20 000+ members of the tiki.org site
- average of 30 people in IRC chatroom
As of now (2007-07), the main challenge is to leverage & coordinate all the people that would want to help. For a new users, it's difficult to find out how to help, who to speak to, etc. This is still true as of 2011-07
Open Source projects are typically very bad at marketing. I have led the Tiki marketing effort in the early days. While better than the average OS project, Tiki deserves better. A little marketing along with exceptional SourceForge activity stats got Tiki noticed. Tiki won some awards in 2003. (See Recognition of the "Tiki revolution" below)
In 2005-2006, Tiki marketing has actually been pretty poor. While the application itself (the code) and improved greatly, from the outside, people can't tell. Tiki won no awards, stats on outside evaluation systems were not really looked at (SF stats, Freshmeat, etc). Everybody was busy with code and no one was focusing on attracting new users. In 2007, this has started to change and I expect more efforts here.
The Open Source community has started noticing the Tiki revolution
- July 2003 Project of the Month on Sourceforge
- Top-10 best rated app on Freshmeat.
- 2003 OSDir Editor's Choice Award for Best Web Application
- "...the breadth and depth of participation and energy here make us think that Tiki could become the next Zope..."
- Top-10 activity ranking on SourceForge until CVS stats were busted in November . I am confident we will be back in top-10 when "The statistics will be reprocessed and aggregate statistics will be recomputed..."
We have started using Tiki to promote Tiki and for the online Tiki documentation. We had a great PDF version 350 page documentation for Tiki 1.6 We have failed to reproduce this in wiki format for 1.7 and so far, for 1.8
Using Tiki for our own internal documentation has made us improves Tiki's multilingual features which are working nicely in Tiki 1.9.x
2007-07: We are now back on track to producing great documentation, thanks to a squad of dedicated volunteers. Please help!
Next step is to improve Tiki to make it easier to make a book.
With 350+ members on SourceForge, we need a way to organize collaboration, communication and teamwork. I think we should enhance the "project management/groupware" aspect of Tiki. Here is a good article on Groupware features:
2007-07: Tiki actually has pretty much all the basics to be a great groupware package, and many people use it that way. However, Tiki community is not yet full leveraging these features.
Everyone who wants to help in Tiki should be clearly identified.
Who they are, what their skills are, what they want to do, and their current level of availability/commitment to the project.
All the info here should be in user profiles. As should SF username, Freshmeat username, IM addresses (Jabber, MSN, IRC, etc).
Users should be able to update their profile. Something like this:
Avoid human bottlenecks.
Regroup people by common interests
Make it easy for people to communicate, collaborate, contribute.
Please see: CRM
In action: Teams
update: organic groups , part of Workspace RoadMap will solve it (for real this time!)
update: Tiki workspaces in Tiki 1.10 is gonna solve all this
update 2007-07: Tiki Workspaces are not officially in 1.10 but part of mods. Some people do it via category permissions. Tiki needs a way to natively handle this type of objective.
- Group ACLs. (Who can view, edit and delete. Ie: We need the possibility to make "secret" groups).
- Users should be able to remove themselves from groups or projects. (like SourceForge) done in 1.10, self-add, self-remove
- Users should have an easy way to apply to groups (which they can see). The group leader gets a message and can accept or reject. (like phpBB)
- Audit Trail on all additions and removals to groups. (and for that matter on all admin settings) (like Tutos) Started in Tiki 1.9.x (tiki logs)
- have listing/filter of members of certain groups. Done a while back in Tiki 1.9.x
- name of group clickable on tiki-admingroups.php
- filter via multi-choice groupname on tiki-adminusers.php
- Smart email to groups
- Send emails or inter-user messages to groups. The message should not duplicate. If I send to two groups and a user is in both, he/she receives only one. Now available in Tiki 1.9.x newsletter
- We need permissions on who can mass mail which group. Now available in Tiki 1.9.x newsletter
Down the road, I'd like to see some sort of ))WikiGraph-like(( OrgChart. Please see: OrgChartDev
Typically, project management software is too rigid and ends up not being used optimally. Users like the free-form of wiki pages. However, reporting and planning becomes a problem.
Twiki seems to have a nice balance: http://twiki.org/cgi-bin/view/Plugins/ActionTrackerPlugin
mose's work on 1.9 trackers looks like a promising way to manage tasks & requests within a project.
Here is how I see it could work:
Each wiki page is a mini-project. Users or groups are associated to a page via a customizable role.
CMS type workflow roles
2007-07: http://dev.tiki.org is start on this type of organization.
Please see: Webmail
2007-07: I have given up on having IMAP in our webmail for now.
2009-06: Jonny added IMAP to Groupmail. Yay!
Please see: CalendarDev for the ultimate calendar feature wish-list. Tiki 1.9.4 calendar is pretty good now
New related project: social event management system
2007-07: Tiki 1.10 has been been seriously updated.
2007-07: While this feature has not become as popular as I thought it would, we are now seeing more & more browser spreadsheets.
2010: spreadsheet now revamped with jQuery.Sheet in Tiki5!
I'd love to be able to sell e-content. Now part of Tiki5!
This is the way to go:
Tiki is excellent to share, to debate, to foster consensus. Most decisions can and should be taken this way.
However, at the end of day, sometimes, there needs to be a vote to decide on an issue and to move on. Either to elect people like Debian:
Or to make a decision for which, we can't "do both".
There are way too many OS CMS projects. This leads to dispersement of talent and energy. My hope is that smaller OS projects merge with larger ones, adding their features and providing data migration scripts. However, I have not noticed much of this happening.
2007-07: I still don't see any evidence of this. I think small projects just die, and that's it.
Leading OS source projects should share & collaborate where possible. Areas where Open Source CMSs should collaborate:
- Calendar data sharing (RSS feeds for calendars) see: phpbeer.com
- Spreadsheet applet
- WYSIWYG editing with multilingual spellchecker.
- CMSML, XFML, OPML
- LGPL Syncml solution in the PHP community (Phpgroupware, Egroupware, Horde, Tiki CMS/Groupware, more.groupware, Tutos, etc)
- OrgChart applet
- More collaboration with cmsreview.com and oscom.org
While Tiki is a CMS and it makes sense to collaborate with CMS associations, Tiki is also a Wiki, so I want to see more involvement with :
2007-07: link is broken, sorry. Please post new link if you find.
We need more job opportunities. It would be really sweet to get Luis back full time ;-)
We need more Tiki hosting companies!
I would like to get Tiki at the same recognition level as Drupal, Joomla, MediaWiki and Wordpress. While time is on our side, we could do better:
- Better self-promotion
- Powered by Tiki icon by default in all templates
- More visibility on Freshmeat (linking these icons to http://freshmeat.net/projects/tiki/ )
- better listing in google & Dmoz
- Updated Tiki descriptions, short/medium/long
- Getting listed on shareware sites (using PAD format)
- banner campaign: ex.: blog + wiki => Tiki CMS/Groupware
- Success stories like twiki.org
2007-07: Tiki is clearly a lot better than it looks.
As Tiki is used more & more, our exceptional dev team always rises to the challenge. We are using high quality components and optimizations will come with demand. The DogFood effect.
2007-07: Mozilla has selected Tiki as the future platform for their support site. They have a lot of experience with high-volume sites and will help improve Tiki in this aspect.
Tiki has succeeded so far because "You can add all you want as long as you make it optional and it doesn't break anything" (orientation given by Luis Argerich)
With enough eyeballs & adopt-a-feature, this is not a problem. People just activate what they need anyway. However, we should do a much better job at informing users of the state of each feature. Maybe a 1-10 score on feature set, maturity/usability, stability, & scalability/performance. We could implement a voluntary reporting of feature usage. This would help us evaluate our scores. For example, our wiki would score very high here but not our blogs. Users should know these facts before activating features or selection Tiki as their solution.
2007-07: This was done on http://doc.tiki.org/features
Now, back to bloating & featuritis, here are my views:
Forks in Open Source projects happen. They can be good or they can be bad.
Bitweaver was launched a while back (originally name TikiPro). I appreciate that the team considers Bitweaver as a sister project. I want to avoid the phpnuke/Postnuke/myphpnuke/xaraya/envolution/xoops/e-xoops/OpenPHPNuke/iXprim/NDPS fiasco.
Relations between Bitweaver & Tiki are cordial and some developers participate to both.
Way back, I wrote: "Hopefully, both projects will re-merge in the future." I guess it's pretty unrealistic at this point, but I still hope it happens…
Tiki is a very difficult project to fork. It is way too big. For sure, if someone forks, they will have to drop some features (maybe even the reason why they choose to fork). But users may need those features…
Anways… I hope there will be no more forks (especially for the wrong reasons). And we will always find ways to make it work.
The quantity of features is a challenge for translators. Do you really want to translate stuff for features you don't use?
I think we should make it easier for partial translations to appear in Tiki. ex.: translate forum & article strings in language X, the rest will appear in English.
Project for 2008:
We need some sort of translation coordinator…
More features, more developers, more code. Let's make sure we always have enough eyeballs!!
Outside Tiki, I am a freelance IT consultant & project manager. I have a business degree from UQAM, specializing in Information Systems. I am a volunteer for a few not-for-profit associations and live in Montréal, Canada with several cats.
You can listen to me in a phone interview for a University in Switzerland
I can be reached at marclaporte at php.net
Thanks for reading!