OSCON 2011 was awesome. We'll be back in 2012. July 16-17-18-19-20.
We'll soon be on this list:
Webinar 2012 07 is normally scheduled for July 19th so we maybe will change the webinar date (exceptionally)
(check the video on YouTube to see all the comments)
Beyond the booth, we'll be participating to several Birds of a Feather (BoF) sessions. Check the schedule at the conference, and you'll find a session about Tiki Wiki CMS Groupware, and another about Tiki Suite. We'll also participate to sessions about Wikis, CMSs, etc.
Table of contents
- Planning notes
- Tiki Wiki CMS Groupware - Software made the Wiki Way
- Why your open source community should be even more open than it is
- In answer to the perennial question: How exactly do you make money being an open source business?
- Looking beyond the product: Community aspects in the selection of open source software
- Enabling Collaboration Using Open Source Enterprise Social Software
- Related links
- propose a session/lighting talk
- propose a BOF
- Flat screen and PC for demoing Tiki (Pascal)
- Banner Stand (Marc)
- promo sheets (Marc)
- Leaflet about suite.tiki.org
- 7"x44" poster as the booth identification sign (if we want to replace the non-branded one)
- A business-card type thing that we can give out all over the place (with booth number?)
- Estimated attendance: 2,500–3,000
Who is planning to attend?
- Mark Laporte
- Greg Martin
The submissions were not accepted[+]
Session type: 40 minute presentation
Tags: wiki, tiki, tikiwiki, cms, wiki way, community, php, software development model, crowdsourcing
Audience level: Intermediate
(brief overview for marketing purposes, max. length 400 characters—about 65 words)
Tiki is an all-in-one PHP application with an open community
- Treating the code itself like a wiki
- With 500 accounts on SourceForge.net with full commit access to the full code base (1M LOC)
What could possibly go wrong?
Come discover how Tiki has become the Open Source Web Application with the most built-in features (no plugins) and how you can make your own project more collaborative
We all know of Wikipedia, which applies the "Wiki Way" to produce a free body of knowledge. This has led, in a very short period, to the biggest project of its kind.
What happens if you use the "Wiki Way" to build software & organize a community? Answer: Tiki, The Open Source Web Application with the most built-in features. How? The Tiki model (tiki.org/Model) has a "Wiki Way" approach to the whole project (code, content, community, etc.). Here are base principles:
- Wiki community & open source
- "Wiki way" participation to the code
- 500 contributors with direct commit access to the whole code base.
- All-in-one codebase
- Inherent synchronized releases (to avoid core vs plugin dependency issues)
- Lots of features, but no duplication
- Dogfood (A community recursively building a community management system)
- Scheduled releases (two major releases per year)
Through the example of the 9 years of the Tiki community, learn about trials and errors, how collaborative communities work and the pros & cons of various community and software development models. Learn about the unique benefits and challenges of the all-in-one model, and how it contrasts to the traditional wisdom of making software.
Tiki Wiki CMS Groupware is a full-featured, web-based, multilingual (40+ languages), tightly integrated, all-in-one Wiki+CMS+Groupware, Free Source Software (GNU/LGPL), using PHP, MySQL, Zend Framework, jQuery and Smarty. Tiki can be used to create all kinds of Web applications, sites, portals, knowledge base, intranets, and extranets. It is actively developed by a very large international community. Highly configurable and modular, all features are optional and administered via a web-based interface.
Tiki goes way beyond just wiki pages and offers collaboration through spreadsheets, image annotations, databases (trackers), etc, and integrates with other open source projects such as BigBlueButton (Audio/Video/Screensharing/Chat) and Kaltura (Collaborative video editing).
(Any other information you wish the organizer to know? If you are proposing a workshop, please tell us what type of learning experience you have in mind (hands-on, demo, etc.). If you selected “Other” in the Session type field, please provide more details here.)
In case you don't know Tiki, a few extra links:
A Process That Is Not: http://www.computer.org/portal/web/csdl/abs/html/mags/so/2009/06/mso2009060004.htm
Tiki is the Top-20 Open Source CMS Market Share Report in 2011 (in 2010, 2009 and 2008 as well)
I have presented Tiki at most of the big OS events (Fosdem, FISL, etc.) We were there in 2011 with a booth, and intend to have a booth once again in 2012. Here is an interview at our booth: http://www.youtube.com/watch?v=Vh6QOp0g1o8
As of now, we "only" have 498 accounts with commit access:
but by the time the conference rolls around, we'll be over 500
This is one of the largest open-source teams in the world, and is in the top 2% of all project teams on Ohloh.
Can an open source community ever be too open? What happens when an open source community embraces Erik Raymond's infamous "bazaar" model to the extreme? What are pros and cons of "letting the community evolve naturally" vs. "running a tight ship"? How can open and seemingly chaotic governance be reconciled with the need for stability, at the same time supporting agility and rapid innovation?
Can an open source community ever be too open? Characterized by an extremely open and collaborative “wiki way to software development”, the Tiki open source community has succeeded, if not thrived. Tiki contributors are among the top 2% of all project teams on Ohloh, a comprehensive directory of open source projects.
The Tiki community is an open organization governed by a social contract developed through consensus, and is very open and welcoming even by open source standards, it is characterized by a highly laissez-faire approach to governance. In fact, an article IEEE's Software magazine (2009) described Tiki as embracing Erik Raymond's “bazaar” model (a reference from his seminal work on open source communities in 1999) to the extreme. For example, unlike many other open source communities, almost anyone can request for source code commit rights in the Tiki community. How then does this community balance needs such as security, stability, agility, innovativeness, and sustainability?
In this talk, I will investigate the factors that lead Tiki to be able to adopt such an open model yet provide enough of a framework for ongoing continuity, addressing common issues faced in the governance of open source communities, evaluating the pros and cons of Tiki's approach in overcoming these challenges. While Tiki's approach may not be for every community, understanding why certain strategies work and not work for it in contrast to other communities reveals lessons learnt that can be applied to all open source communities.
In Tiki, who decides how the application is extended and which features take priority? Nobody in particular. A single, flat wish list exists on the developer portal: anyone can add a feature request to the list, and anyone can pick any item from the wish list and pursue it. Contributors create wiki pages and rally support around their work by promoting it through the mailing list.
Quality is self-regulated by the culture. Yes, there is a “Quality Team” that monitors and approves commits destined for the stable branches of the software, but the development branches are pretty much free-for-all. Release time is extremely important to the Tiki community, and TikiFests, coding sprees where developers gather from all around the world both in person and through online voice/video conferencing is where most of the decisions related to a release of a new version are taken. The highly collaborative approach to development at Tiki creates a unified environment where users need not worry about upgrade dependencies on third-party patches or tens of plug-ins which is often the case with many open source projects where development is more of a contest between competing plug-ins.
As a countervailing measure to the often chaotic and unruly nature of extremely open contribution, the Tiki project has well documented contribution principles, guidelines for newbies, rules of engagement, suggested development practices and patterns, mentoring, a solid central infrastructure, an issue-tracking system, extensive user documentation, a feature list, a user rating system, and so on... The Tiki way clearly supports human centricity, pragmatism, empiricism, and experimentation. It may not be as efficient as top-down managed approaches, but this is made up for by the collaborative contributions of a growing and committed community.
Towards more stable governance, Tiki has recently also established the Tiki Software Community Association (which we will call the Foundation), a non-profit with governance similar to the Apache Software Foundation that represents the collective needs of members of the community. In reflecting the open nature of the community, the Foundation is not controlled by any one company and functions effectively as an arbiter of differing needs, in the management of community trademarks, and in community development. It is to be noted that within the Tiki community there are a wide range of groups within which individuals can lead and participate (such as Documentation Editorial Board, Promotions/Communications Team) without being Foundation directors, and the Foundation has no direct jurisdiction over these groups which are independently formed, even though it does provide hands-off oversight and does regulate the proper use of community trademarks (Tiki brand and logo).
Diversity is Tiki's strength, and very much a strength of open source in general. Openness leads to increased diversity and its associated benefits but can also lead to challenges. By dissecting one of the most open communities in open source today, this talk hopes to shed light on how a delicate balance between openness and stability can be achieved.
(Submitted by Nelson)
Everywhere I go, people ask me "So you sell open source software? Isn't open source software free? How do you make money?" This talk is one that I've been giving at a number of business conferences, explaining exactly how open source is absolutely key to the competitive advantage I have in the marketplace, which is tapping into the ecosystem. Ample time will be provided for Q and A.
- Introduction to company and open source community as a case study
- Company's competitive advantage: open source's contribution to the bottom line
- Ways that open source reduces costs
- How open source enhances revenue potential
- Brief explanation of Osterwalder and Pigneur's (2009) framework for ecosystem based businesses (http://businessmodelgeneration.com/)
- Three components that make up the business model of any company: Infrastructure, Product Innovation, Customer Relationships
- What is your focus? What can the ecosystem deliver?
- The business model in detail: Infrastructure
- Key partners
- Key resources
- Key activities
- The business model in detail: Product Innovation
- Delivering the value proposition
- The business model in detail: Customer Relationships
- Customer relationships
- Customer segments
- Mapping the ecosystem (based on Bloom and Dees' article in the Stanford Social Innovation Review, 2008)
- Resource providers
- Pros and cons of open source for users
- Pros: No lock in, choice of multiple consultants, power to the implementors, can always fix it yourself
- Cons: Too much choice, total cost of ownership is not zero, power to the implementors (vs. managers), lack of understanding of open source culture and licenses
- Strategies to tap into the ecosystem
- Ways of participating in the open source community (development, funding, governance, knowledge brokering, documentation, communications)
- Ways of adding value (links to other open source projects, participation in industry groups)
- Strategic positioning of company viz-a-viz keystone organization or being a keystone organization
- Differences in strategy depending on who owns the technology (community or company owned open source technology)
Most of us look primarily at technical criteria when selecting open source software. However, unlike closed source software it can be important to consider community aspects as well. After all, even if one has no intention to contribute back or interact extensively with community members, significant cost savings can result from leveraging community resources for support or customization needs.
If a company's open source strategy is limited to acting as end user of open source software, is there a business need to understand the nature of open source communities? Should it be the goal of all businesses to become an active participant in open source communities, or become recognized as a significant contributor? What does it really mean to participate in an open source software community, even if it is just as a user?
Business users of open source software can broadly be divided into those who use open source software as end-users, and those who incorporate underlying open source technology into their products and services. This talk will address both these groups by explaining important facets of understanding and evaluating community in the selection of open source software, and then elaborate on the role of active participation in open source communities to enhance the value that can be obtained from the use of open source.
Important criteria that should be considered when evaluating open source software include the size and vibrancy of the community. One source for such information is statistics on sites such as SourceForge and Ohloh. However, both sites focus on the contribution of developers and it is important to note that contribution to an open source community is more than just commits to the codebase. As in commercial software, production of good open source software also requires documentation, testing, support, training, and the incorporation of user feedback. An evaluation of an open source community should also consider the broader ecosystem in which it exists.
Selecting from a final shortlist of software will often require a tradeoff between access to more advanced or specialized functionality, and the size of its community. Software that provides more advanced functionality can have smaller communities due to its more specialized nature. A deeper understanding of the nature of the community is also critical in determining the nature of support that will be available for an open source software. It is important to consider the nature of the resources the community has to offer in relation to the capabilities of your organization, for example, is the community rich in technical experts, less technical design-oriented individuals, or business process experts. What skills best complement those that you have in your organization?
Businesses incorporating open source software into their products or need substantial extensions to functionality may want to consider leading the development and ongoing maintenance of a new component. This could lead to benefits that come through influential leadership of a new sub-community which can provide ongoing support and resources. The larger the potential sub-community is, the greater the benefits will be, but greater also are the risks and the costs. Maintaining a component is likely to be a very involved effort and there is also the question whether demand for that component will grow sufficiently to make it important enough to the community as a whole. Creating a component has to be weighed against the alternative of participating actively within an established group of developers where the component is already in existence.
When working with open source software, it is important to consider the roadmap of the community and evaluate if it matches one's desired use and objectives. Unlike closed source software where the product roadmap is defined by management, the roadmap of open source software is in a constant state of flux influenced by the community of users, developers, and other contributors. Understanding where a community is headed requires a perceptive evaluation of the individual motivations of the various stakeholders involved.
Businesses who intend to participate actively through contributing code back to the community, especially those whose products depend on the open source software, will have to gain an appreciation of the different cultures that exist in each community in order to maintain a cordial working relationship as participation becomes progressively involved. Open source communities may become suspicious of corporate intentions if they are perceived as being in conflict with the needs of existing members. It is often better to be as open as possible up front about one's plans, especially with key members of the community. Most open source communities are characterized by more open policy discussions using tools like wikis, forums, and mailing lists than is typical in corporate environments. It is also important to be aware of the software development management procedures that are in place in the community, many of which are likely to differ from those used by your organization.
Companies that depend on open source software as components for their products or services could aim to rise to leadership positions of influence within the communities they participate in. The path to leadership involves initiating conversations with users who have not previously contributed to encourage them to be more involved, depending on the goals of the contributor, and the amount of time available to work on related items. Members with ideas, patches or documentation but who have no time to integrate them can be introduced to other contributors so that they can collaborative on getting more resources into the community.
Understanding the community which develops the software being used by a business provides many benefits. As an end user, the company is able to access support channels traditionally not available with closed software solutions. As an active participant, the company has the opportunity to influence the direction of the software, and if desired, to leverage that influence as part of its business strategy.
(not submitting this one in 2012)
There are many enterprise social software solutions available today such as Sharepoint and enterprise wikis. This talk will show you how to use the open source Tiki Wiki CMS Groupware, the 9th best open source application in InfoWorld's 2010 Best of Open Source Software Awards, to enhance collaboration and knowledge sharing using wikis, blogs, forums, enterprise social networking, file galleries.
Tiki Wiki CMS Groupware is a powerful, multilingual enterprise social software. Translated to 35 languages, and with an install base of tens of thousands, over 200 people have contributed to the source code and it provides hundreds of built-in features to create all sorts of collaborative web platforms, intranets and extranets.
While not as widely adopted as MediaWiki, Tiki is a more comprehensive all-in-one collaboration suite incorporating features including articles (for news, press releases, etc...), forums, email newsletters, blogs, file/image galleries, structured data trackers/databases, translation, polls, calendar, RSS feeds, and more. It is also integrated with other open source projects: BigBlueButton (Audio/Video/Screensharing/Chat) and Kaltura (Video Editing and Streaming).
In Tiki, a fine-grained role-based privilege system allows you to set up a site with the custom access policies you need for your organization, based on the user groups that you define. Revision tracking is built into the system, and new edits to content can be restricted to viewing by select groups until they are approved. Categorization and tagging are extremely flexible and powerful.
This talk will walk through how to use Tiki for a corporate Enterprise 2.0 intranet/extranet incorporating a wiki, blogs, forums, enterprise social networking, and file galleries.