Table of contents | |
| |
Tiki Vision (What?) | |
|
| |
Tiki Web Operating System | |
|
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. Use Cases
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
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 | |
Project Management (How?) | |
|
| |
A little history | |
|
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". | |
Recruit Early, Recruit Often | |
|
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. | |
Adopt-a-feature | |
|
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.
| |
Comparison to Postnuke | |
|
Previously to Tiki, I was using Postnuke. Postnuke has a great thing going in terms of userbase. However, the dispersement of code & documentation was problematic. I think we should try to keep things centralized.
| |
What has been accomplished (What happened) | |
|
| |
Yeah, Tiki does that! | |
|
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 portability and respect of standards | |
| |
The DogFood effect | |
|
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
| |
Great Partnerships & Components | |
|
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 great community | |
|
IMHO, the main challenge (currently) for Tiki is the lack of eyeballs for such a complex project. As more & more people adopt Tiki in the coming weeks & months, I expect (and hope) the stable versions will become more stable and the cvs version will continue to grow rapidly in features.
We now have over 450 members on SF from across the globe
| |
A little marketing | |
|
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.
| |
Recognition of the "Tiki revolution" | |
|
The Open Source community has started noticing the Tiki revolution
| |
Now what? | |
|
| |
Eating our own dogfood, Finish part 1 (Documentation) | |
|
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.
| |
Eating our own dogfood, part 2 (project management/groupware) | |
|
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. | |
A CRM approach to managing volunteers | |
|
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:
The goal:
Please see: CRM | |
Better group management | |
|
In action: Teams
| |
Wiki-based Project management (adopt-a-feature DogFood) | |
|
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.
Each wiki page is a mini-project. Users or groups are associated to a page via a customizable role. Possible roles:
CMS type workflow roles
| |
IMAP email solution like IMP, Squirrel or moregroupware | |
|
2007-07: I have given up on having IMAP in our webmail for now. 2009-06: Jonny added IMAP to Groupmail. Yay! | |
Powerful calendaring solution | |
|
New related project: social event management system 2007-07: Tiki 1.10 has been been seriously updated.
| |
Other missing features of a web operating system: | |
A basic spreadsheet in Tiki: | |
|
TikiSheet : spreadsheet in your browser: in testing! 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! | |
E-commerce | |
|
I'd love to be able to sell e-content. Now part of Tiki5! This is the way to go:
| |
Voting & decision making | |
|
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:
Please also see:
| |
More partnerships | |
|
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:
http://wikiohana.net/
| |
Tiki companies | |
|
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!
| |
Tiki visibility to the next level | |
|
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:
| |
Pitfalls (What could go wrong?) | |
What doesn't worry me | |
Performance/scalability | |
|
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 bloating & featuritis | |
|
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:
| |
What worries me | |
Too many forks | |
|
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.
| |
Translations | |
|
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… | |
Security risks. | |
|
More features, more developers, more code. Let's make sure we always have enough eyeballs!!
-
You can listen to me in a phone interview for a University in Switzerland I can be reached at marclaporte at php.net I am run a Tiki-centric business with an Open source business model and I am always available for more Tiki projects. I routinely hire members of the Tiki community for these projects. My personal site: http://marclaporte.com
Thanks for reading! M 😉 --
alias
| |