Deployment Platform/Declaration of purpose

What are you trying to do?

• Create the ability to launch Base Software within heterogeneous software and hardware environments.
• Using Base Software, provide access to varieties of Content created within the Sugar community, such as Sugar activities, artifacts derived from Sugar activities, books, etc.
• Using Base Software, provide the collaborative functionality to support community Social activity centered around the Content.
• Provide tools and workflows to adapt the Content and Base Software to specific needs that a Sugar Deployment might face, including limitations like off-line environments and restricting hardware.

How is it done today, and what are the limits of current practice?

• There is no systematic approach to provide the same Base software:
  • On different GNU/Linux distributions. This makes coordination difficult, on the Sugar Labs level, for any efforts related to Base software.
  • On the Sugar Labs level, there are no Long Term Support, LTS, Sucrose releases. It makes coordination difficult between Sugar deployments.
• The current means to share Content is either too general or too limited:
  • The Sugar Activity Library is needlessly centralized (by the design of the upstream project that Activity Library is based on) and, e.g., it doesn't accept uploading of experimental versions of existing activities created by any new authors.
  • The Activity Library is too restrictive in the case of non-trivial software, e.g., dependencies and binary-based activities (by upstream design). It was created to handle Firefox plugins.
  • There are no services similar to Activity Library to share something different from activities.
• There is no centralized Sugar-way to support Social activity within the community:
  • There is a communications gap between developers and users in the field.
  • The existing social services are either scattered or too technical.
• There is not a systems approach, on Sugar Labs' level, to coordinate efforts within the Sugar deployments.

What's new in your approach, and why do you think it will be successful?

• We use the Open Build Service for a systematic approach to provide the same Base software:
  • The same code base is being built for all supported GNU/Linux distributions.
  • Among the 6 months Sucrose releases, there will be Long Term Supported releases.
• We provide the Sugar Network to systematically share a broad variety of Content.
  • This will include Sugar activities, Sweets will take care about processing dependencies, and the Open Build Service will build binaries automatically.
• Sugar Network is also an integrated approach to provide Social activity for the Content.
• Sugar Network is designed to fulfill specific deployment needs like the following:
  • Supporting environments with limited, or non-existent, access to the Internet;
  • Adapt Content to local needs.

Who cares?

• Individual users;
• Content creators and software developers;
• Existing and future Sugar deployments.

If you're successful, what difference will it make?

• Individual users will receive these benefits:
  • A reliable way to start Sugar on all mainstream platforms;
  • An environment to share content, activities, and collaborations that are well integrated with Sugar community workflows and learning.
• Content creators and software developers will obtain these services:
  • Easy sharing of software, e.g., the system will handle issues like dependencies and the building from sources automatically.
• Existing and future Sugar deployments will enjoy these services:
  • A sharing space that will be common to all participants (but one that supports the tuning of content for local needs);
  • Accessible templates of deployment practices and procedures to more effectively reuse deployment experience. Such experience will be incarnate in solutions on the community level for reuse in any deployment.