Model
Video | |
|
| |
Model | |
Wiki community | |
|
It's a Do-ocracy. Everyone is a volunteer. Things get done because someone like you decides to take the time to make it better. Join a team! Participate in a TikiFest!
| |
Software made the wiki way | |
|
Reflecting one of its core features, the wiki, a catchphrase for the project's development is "Software Made the Wiki Way". What this means is that the strengths of wiki-style collaboration for building knowledge bases — relatively free access to create and edit information in an essentially flat, bottleneck-free organization — can also be applied to the project's software development process itself. Virtually anyone can contribute code additions and changes to the Tiki project. While many Open Source communities have a send-a-patch-and-someone-else-will-commit approach* We use this method for commits to the stable branch (Ex.: 3.1 -> 3.2 -> 3.3) but when developing the new major version (ex.: 3.x to 4.0), all contributors commit directly to the main code base. We feel this is a great balance of
There isn't any pre-commit evaluation procedure; developers are given access to commit and are encouraged to simply submit bug fixes or feature enhancements directly. Feature additions and other extensive changes can be done in an experimental branch and then merged into the main development branch. The more active members of the Tiki community informally monitor the commits of new participants. Code contributions such as new features are marked as "Experimental" in the Tiki site administration panel. As a feature gains traction as a useful one to continue, then it is maintained along with all of the Tiki code. Features that don't gain that traction or ones that are made redundant by other, better features and so on are given an "Endangered" label, and a path to migrate away from them is provided as they are removed from the code. In this manner, the wiki way of software development makes participation easy and protects the quality of the code over time. This method reflects the general approach of Agile software development model; specifically, being a mature software project in which development is mainly feature addition and code improvement, Tiki has much in common with the Feature-Driven Development method. The 12 principles of Agile software development generally apply to Tiki software development process, although regarding "Face-to-face conversation is the best form of communication (co-location)," the Tiki project has always relied on the remote participation of its international community of developers, with only occasional in-person meetings (our "TikiFests"). The developers use the Tiki software itself to communicate, collaborate, track issues and so forth, so the software is tested and improved as it is used (sometimes referred to as "eating our dogfood", as described below). | |
Scheduled releases | |
|
Scheduled releases are a fundamental part of the Tiki model. As a large community, it makes it clear for everyone what to expect. There is a major release every eight months (adjusted from the previous two major releases per year), with several minor releases in between. Please see: Roadmap and Version lifecycle and When to release - think popcorn. Whatever is not ready in time for one release is pushed back to the next. If you are late for a train, you may miss it, but you'll be early for the next one .
Why every eight months? Why not four, six, or twelve?"
Six to eight months was just about right. It's long enough to make big changes, yet it's short enough that you don't have to wait forever. For people in a business setting, it's essential for them to be able to a commit to a date with their customer. By having a set date, there is an incentive to commit to trunk, and know when it will become stable. People who need a slower cycle can use LTS.
How can we know there will be enough new features to justify a major release?"
| |
All-in-one co | |
|
All functionality is in the core. Developers are collaborating throughout the whole co Inherent synchronized releasesReleases take more planning and coordination because all the features are released at once, but since it's de facto Synchronized Releases, the whole community can collaborate right away on the next release and this permits rapid major releases (even with such a vast code base). See lifecycle. ;Compare Tiki's all-in-one model, which makes it resistant to the typical issues faced by other applications, as explained by CMS Wire (Jan. 5, 2011):
Yes, Drupal 7 is officially available for download. But it's important to recognize that this is just the Drupal 7 core — the release status obviously does not apply to the thousands of modules (add-ons) contributed by the community. Although there has been much support from the community that supplies contributed modules, and an entire movement that pledged to have their modules D7 ready by release time, it hasn't exactly happened."
| |
Lots of features, but no duplication | |
|
Tiki is a "one-stop shop" with tons of features. In fact, as mentioned, Tiki is the FLOSS web application with the most built-in features. However, there is just one forum, one blog, etc. Having duplicate features would lead to all kinds of problems and would splinter our user and developer base. If several people want to improve a feature, they collaborate and extend, in the wiki spirit. This is why we can give specifically descriptive names like Tiki blog, Tiki forum, etc On Wikipedia, when two pages are about the same topics, they are merged:
| |
All features are optional.
Dogfood | |
|
We eat our own Dogfood and we hope you will as well | |
FAQ | |
|
| |
Decision-making & Governance | |
|
DecisionsTiki is a do-ocracy. Join a team!
Ok, but who decides?"
No offense but sounds like a 'hippie mumbo jumbo'. If the shit hits the fan, who decides?"
Ok, but what if these people make a really bad decision?"
Ok, ok, but what are the general priorities of the community?"
Is it backed by a big business?"
Is there an association?Tiki is community-managed and open development is pursued by an official Tiki Software Community Association. What is the business model?Tiki as a project, has modest expenses, which are covered by donations and affiliate partner relationships. It doesn't need a "business model" like a company that has expenses or employees to pay. While consultants are available for hire, Tiki is "Community Open Source" and not "Commercial open source". If you would like to hire or offer Tiki services, please see business models. Is it sustainable?Absolutely! Various Tiki contributors can come and go, but Tiki, as a project and community will continue no matter what. No one can lock down the code and require people to pay for it. Tiki evolution and development are in no way, shape or fashion the result of VC funding. Who contributes to Tiki?Users, just like you! Typically,
LicenseTiki is LGPL 2.1
Ok, but is it really free? I want to develop websites and I don't want my customers to know I am using Tiki."
Will it always be free?"
Core and module developers
In CMS [add your CMS name here], there is the core and there are third-party modules. There are core developers and modules developers."
Why don't you fix/improve the existing features instead of adding new ones?This is a common concern/frustration of users. Especially when struggling with a bug. Who would decide the priorities? Person A may think the priority is to improve feature X, but for person B, feature X is good enough, and adding Feature Y is more important. Of course, each person will tend to think their thing is the most important. Tiki is a do-ocracy. Tiki is a diverse community. While Tiki is central to the livelihood of many people, they don't work for Tiki. They work for various entities that use, love, depend on, contribute to and want to see Tiki improve as a project. But each has his or her own priorities. This diversity is part of the strength of the project. The answer is that different people that work on different things. The WishList has that name because lists things that people wish for. These can be bug fixes, feature requests, etc. The line between a bug fix and a feature request is often muddled. Even if we somehow did stop people from adding new features (imagine the discussions!), would they really re-allocate their energy to fixing bugs? Since they may need a specific feature for a project, so if they are not allowed to contribute, perhaps they would use another CMS/framework or they would do it anyway but not contribute. None of which is in Tiki's interest. Drawing the lineWhy don't you draw the line and say, "this is what we do and that's it"?
I reported a bug several months ago and it has not been fixedPretty much the same answer as "Why don't you fix/improve the existing features instead of adding new ones?" above. Are features ever removed?Yes, but with care and consensus. We want to keep upgrades easy. The goal is to have a useful application. Typically, features are removed because of the evolution of browsers or the web makes them obsolete. Or it could be because another feature in Tiki becomes so powerful that it makes this one useless. In a traditional small-core-and-tons-of-extensions model, code will die off on its own by a lack of interest. In the wiki way, the community must proactively do housecleaning. This is much like wiki pages, which should be re-factored, deleted or merged. Please see: Endangered Features. Will features continue to be added forever?Well, that depends on the people that participate in the community. So far, the number of features has been an asset, not a liability. Should this change, we'll adapt at that time. It doesn't matter how many features you offer, people still ask for more. Of all the innovations, the rate of the totally new features has been slowing and what we see a lot is how various features are each improving and blending more tightly with other features, for example, Pretty Tracker. You can shape the future of Tiki . Continuity
How can I know Tiki will be there in 5 or 10 years? What about stability/long-term support?"
So Tiki will be around. But how good will it be? Well, the rate of evolution, innovation, etc. depends on the participation of people just like you . Thus, think long-term. Overall, we should be mindful about how our immediate actions fit in the long-term. Tiki will never be "finished" so any shortcuts now can come to bite us down the road (especially if someone else is stuck cleaning up the mess). See: Maintainability. | |
All-in-one model | |
|
Tiki has an all-in-one approach to features. Think of it as a suite of applications like Open Office. The features are built in and all optional instead of offered via third-party modules/extensions/plugins. Because of this model (and the open participation), Tiki has more built-in features than any other Open Source web app. (If you know of one, please let us know!) Best-of-breed applications
I prefer a collection of best-of-breed applications that I assemble."
Lean apps / complexity
I like simple apps because I can easily tweak the code to my liking."
Survival of the fittest
Most other CMS systems have several "modules" to choose from. Since there is competition among the "modules", it is the survival of the fittest."
Yes, but competition is good."
Competition is not the only path to innovation. Say you wanted to have the best possible definition for a word on Wikipedia and you have nine volunteers to help. What would you do? Would you create three teams of three and pick the best definition? Or would you have all nine people collaborate? If you split into three teams, chances are, when you evaluate what the three teams came up with, each team will have something you like. Yet, by picking one team and discarding the two others, you are wasting talent, motivation and energy. Now, it makes perfect sense to split the nine people in smaller teams according to specific responsibilities towards a common goal. If this model makes perfect sense to generate content for Wikipedia, why is it not a good model for software development? Imagine two communities of the same size. One with the competition model and the other, with the collaboration model. Which one will have the most code review? which one will have more code/functionality duplication? Feature interaction problem
Features in the core generally tend to interact better together than external code. So how is this in Tiki?"
Lack of feature development
If there is only one of each feature, what happens when it doesn't do what I want/need?"
Yes, but System Z has hundreds of modules. Here are extensions and third-party modules listings of popular PHP applications:
The important question is: "does the system do what you need now and for the foreseeable future". (This is just as true if you are picking Tiki vs another solution) Tiki has over 1500 preferences/features/settings built-in, vs the sometimes 10,000+ external extensions/mods/plugins of some fine applications. But let's not forget that some of those external packages are features duplication. The important thing is, do you see a feature that you want / need that is not offered by Tiki (please see feature list, modules list, mods list and all plugins). Feature-creep
What about feature-creep? If you let just anyone add anything, it'll be chaos."
Tiki is a shared resource. We want it to be useful for various people, to solve various needs, in various contexts. If it's not solving your problem, chances are, an enhancement would be useful to other people. The trick is to try to use and extend the existing feature set. If there is nothing there that can help, it's to translate your need into something as generic as possible, so many problems can be solved with the same code, by changing labels or flipping a few switches. Of course, it's tricky to know this if you are new to the application, so you can work with the community to find solutions. A good example (of a generic feature) is trackers. Trackers are a database, forms and report builder, so you can create a bug trackers, a to-do list, a mini-CRM, etc, whatever you want. You can build unlimited custom applications specifically tailored to your needs. The real challenge is to find a technical and organizational way to deal with the Law of Software Envelopment. Tiki8 has filters in the admin panels which will lower the learning curve.
But too many features is confusing!"
Yes, it can be. If you don't use a feature, don't activate it! And Tiki's Profiles (http://profiles.tiki.org) are there to help.
I just need a [add your feature name here]. This site is just a hobby, won't be big and professional like. . . ."
Dead-end features / Dependency hell
I was using system X. My problem: I was using a third-party module. It is no longer supported. The developer has given up. I can't upgrade my site without breaking the module. Could this happen to me with Tiki?"
Reinventing the wheel
Tiki is like its own world, it is always reinventing the wheel."
Yes, but what about phpBB?"
In reality, Tiki relies heavily on External Libraries, to have less code to maintain and to leverage other projects' experience. We try to contribute back (upstream) as much as possible. More than half of the code included in Tiki is from other FOSS projects. Waste of disk space
Yes, but Tiki take a lot of disk space, especially for a PHP application."
Performance
Tiki is really slow, consumes a lot of RAM and CPU cycles."
Yes, but even for anonymous users, Tiki uses way more resources (SQL queries, RAM, etc.) than other CMSs."
SecurityBottom line: Systems that are heavily reliant on plug-ins are more apt to have security vulnerabilities for which there is no known patch. Why is this? Even frequently-used plug-ins are not always actively maintained and enhanced by their original developers. Source Another risk: http://wpmu.org/why-you-should-never-search-for-free-wordpress-themes-in-google-or-anywhere-else/ Tiki doesn't permit PHP code in templates (by default but can be changed by the admin), which is a nice benefit of Smarty. On the other hand, Tiki has more code. And more code is more potential issues. Our solution to this is simple but effective: Each file in Tiki has a feature-check, which essentially renders the file inactive. If a security vulnerability is disclosed, admins can turn off that feature. Both models have risks. We feel it's a good trade-off. API
Yes, but system Y has an API."
Tiki has no formal "API" but has several ways to connect/enhance/interact. It is designed to be easy to add functionality. Do you think over 300 people would have contributed via SVN if it was difficult? Hello World. Now, depending on what people are trying to do, they should look at Webservices, Plugins, Mods, Trackers, Interaction, External Authentication, etc. Extensibility
Examples of success with plugin model
Yes, but Firefox uses the plugin model and it's very successful."
There is no question that the plugin model can and does work. This is to illustrate and explain how/why the all-in-one model works for Tiki.
Experimental
But what if a feature is not good (yet)?"
Once a feature works (even if basic), it can be added to the main code base and tagged as Experimental. Is the Tiki model better?It is very risky to say something is better. The answer is it depends. The Tiki model works for Tiki. And the community will adapt as needed. The Tiki model has benefits and drawbacks, therefore, the Tiki project has different challenges to tackle than other comparable projects. In the small-core-and-thousands-of-extensions model, an important core competency is the package management and the big challenge is dependency hell, which has prompted calls for Synchronized Releases. Tiki has always, by its all-in-one model, had synchronized releases. However, this brings another set of challenges. (There is no free lunch!) Benefits
Drawbacks
For example, Tiki has one full documentation set for the whole application (over 1000 pages). It would be more difficult, but not impossible, to make a similar resource with the small core/thousands of extensions model. | |
Open participation | |
If you let everyone contribute, it'll be chaos. How can it possibly work?That is what some said about http://wikipedia.org/ Conflicts
If I add my features to the core, then, any of hundreds of people can break my code!"
Why would they possibly want to do that?
If you let "just anyone" participate, won't you get in trouble with malicious or incompetent people?"
Documentation
The documentation is missing, incorrect, out of date or just plain bad."
The good news is that it's a wiki, so please log in and fix it. If you know it's wrong but don't know what is right, ask in the Mailing Lists, forums, irc.tiki.org or wikisuite.chat.
The project should disallow code submissions without documentation updates."
Some could argue that it's preferred to focus developers on adding/fixing features and it's up to the documentation team to handle documentation. Whose job would it be to refuse (roll back!) a wanted feature because the developer didn't document? Can you imagine the debates there would be? What often happens: Developers put up basic documentation, enough so that end-users get an idea of what the code does, and then these people can write proper documentation (hopefully with screenshots) from an end-users' perspective. Power users can also "interview" developers and capture this information for the documentation. Code quality
The code sucks and is inconsistent."
Take any open source application and ask around if the code is good, is modular, scalable, etc. Someone will always find something to complain about. A "critique" is very easy. I am sure if some of your work is available to public scrutiny, you will know what I mean . The question should be: Does it work or not? Does it solve my needs for now and the foreseeable future? Can I improve it? Most people use Tiki without changing any code. So code structure/philosophy/organization is of no importance to them. They just want something that works and something that they can upgrade easily over time. Also, Tiki was started with the technologies available in: PHP 4, MySQL 3, Smarty 2, and no jQuery! The good news is that various parts of Tiki undergo massive improvements. For example:
The code is not modular enough."
I am a professional. Really, Tiki's design sucks. It should be more object-oriented."
Please also see: I know this is all wrong, but fear it might be right.
Tiki's design sucks. It's too big. It won't scale. It will implode. It's impossible to have so many features."
Not only does it have a ton of features, it also has a very fast release cycle. Many powerful web apps have a release cycle of one and a half or two years (for the core; modules evolves faster), whereas it is every eight months for Tiki. The Tiki model can't work
If it's not run like a professional project, it will fail."
For many years, some people have expressed these concerns. There was a lot of FUD being spread around. Perhaps Tiki is like Wikipedia and is "is one of those things impossible in theory, but possible in practice.". However, here we are. Tiki is over 17 years old. It's a mature, very powerful application, with a large community of contributors, with tons of features and which is tons of websites & Intranets. Of course, there are a lot of things to improve and there will always be. Remember: if you don't need a feature, don't activate it. However, if you need it in the future, it's only a few clicks away. And remember also, Tiki is open source and open development. You can participate in its future. A glance back - Tiki wins a Bossie!
| |
Things you can pretty much only do in an all-in-one model | |
| |
Page content todo | |
| |
Alias | |