Loading...
 

OSCON2011

Table of contents

Planning notes

Stuff todo

Stuff to bring

Attendees

Who is planning to attend?

  • Mark Laporte
  • Greg Martin

Submissions

The submissions were not accepted

Tiki Wiki CMS Groupware - Software made the Wiki Way

[+]

Description

(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

Abstract

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.

About Tiki
------
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).

Additional Notes

(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)
http://www.waterandstone.com/book/2011-open-source-cms-market-share-report

And: http://tiki.org/Model

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:
http://sourceforge.net/project/memberlist.php?group_id=64258
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.
http://www.ohloh.net/p/tikiwiki/factoids/

Why your open source community should be even more open than it is

[+]

Abstract


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.

In answer to the perennial question: How exactly do you make money being an open source business?

[+]

Abstract

  1. Introduction to company and open source community as a case study
  2. Company's competitive advantage: open source's contribution to the bottom line
    • Ways that open source reduces costs
    • How open source enhances revenue potential
  3. 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?
  4. The business model in detail: Infrastructure
    • Key partners
    • Key resources
    • Key activities
  5. The business model in detail: Product Innovation
    • Delivering the value proposition
  6. The business model in detail: Customer Relationships
    • Customer relationships
    • Customer segments
    • Channels
  7. Mapping the ecosystem (based on Bloom and Dees' article in the Stanford Social Innovation Review, 2008)
    • Resource providers
    • Competitors
    • Complementors
    • Customers
    • Bystanders
    • Detractors
  8. 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
  9. 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)

Looking beyond the product: Community aspects in the selection of open source software

[+]

Abstract

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.

Enabling Collaboration Using Open Source Enterprise Social Software

[+]

Abstract


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.

Related links

alias
Created by: Last Modification: Monday 25 June 2012 16:22:24 GMT-0000 by Marc Laporte
List Slides