This document is under active development!

Use Issue 4 to discuss this document. Bear in mind, this is a really rough draft that we will use as our starting point. As we move forward, this document will take shape and assume a more polished look.

This document must not be dry and boring!

Keep this document entertaining (e.g. use humor) so that people actually want to read it and it gets maintained, otherwise this document will be useless.

Introduction

Purpose

The purpose of this document is to specify the requirements for the KipOpen Application (i.e. the web application) in a simple and easy to understand manner.

Scope

This document is intended to be easily readable by any average or non-technical user.

Reference Documents

Technical design specification.

Project Overview

This content is included in the home page, skip as needed.

The Problem

The lack of sustainable sources of capital for open projects and Open Intellectual Property (OIP) in general.

While the collaborative development model of open projects can be sound, the economics of the system are weak. Today most open projects are largely funded by aggregate donations, and/or corporate sponsorships; this is not sustainable in the long term.

For widespread adoption of open technology in the consumer market (not only in niche markets): informed consumers must understand the value (and the cost) of open technology and engineers and developers must make a living.

The goal of the KipOpen project is to find alternative funding models that do not rely on donations but on tangible returns for consumers; incentives for them to invest on open technology.

We don’t claim to have a solution that solves the funding problem for every sector of technology; this would be naive. The funding problem looks different for every sector and must be tackled by passionate individuals specializing in those sectors (e.g. it would be futile for a hardware engineer to expect to solve the problem for open academic research).

KipOpen is simply a platform that incentivizes individuals from different technology sectors to find appropriate solutions.

What is KipOpen?

A web application

KipOpen is a self-hosted web application. Anyone can download and install KipOpen in their own computer to host a crowdfunding site.

The application comes with the minimal core functionality required to operate in small computing devices (e.g. single board computers) and it has a pluggable architecture to support the addition of extra functionality (e.g. research category plugin, hardware category plugin, Bitcoin payments plugin, Facebook/Twitter integration plugin, French language plugin …etc).

A decentralized network

Each individual crowdfunding site is part of a decentralized network of KipOpen web applications. Peer to peer communication and a distributed database allows every crowdfunding site to share important information with each other (e.g. project/developer reviews, user credentials, projects information …etc).

The following is a simplified diagram of the network architecture: A new user sees KipOpen as a large crowdfunding platform. But It accesses the network through particular crowdfunding sites that communicate among themselves (i.e. network nodes).

KipOpen Sites (Instances)
The grey circles represent KipOpen crowdfunding sites. Peer to peer communication between sites is represented with the black arrows. Users/Investors are represented by the white circles and gray arrows.

Each crowdfunding site hosts open technology projects. These projects generate a profit for the developer(s), a commission for the site’s administrator and a tangible return for the individuals and the community (an economically viable alternative for all parties). Read more about KipOpen Competitive advantage.

The long-term goal of the KipOpen application is to provide a completely open alternative path for the design and development of consumer products. KipOpen incentivizes individual players (potentially from different countries) specializing in different market sectors to host crowdfunding sites specially tailored towards the problem of funding of open technologies in those sectors. For example in our future we would expect crowdfunding sites in multiple regions (and languages) specializing in any of the following categories:

  • Technology Research.

  • Hardware Design.

  • Firmware Development.

  • Mechanical Design.

  • Industrial Design.

  • Software Development.

  • Manufacturing and Retailing.

Through the use of an investment platform designed solely for the development of open technology products, we aim to incentivize the use of public capital (i.e. from pools of informed consumers) to fund every stage of the design cycle. This is in contrast to the use of private venture capital for funding the development of closed/proprietary technology (which is our current standard) and the use of popular crowdsourcing sites for funding flashy proprietary tech products by uninformed or misled consumers.

User Characteristics

The platform has three main kinds of users and there is a lot of overlap:

Platform Administrator/Host

The platform administrator is the individual that downloads the web application and installs it in his own small computer (e.g. it can be a spare low power net-book, or it can be an old server, a single board computer, a Game Boy - not really …etc.). This person is in charge of maintaining his local crowdfunding site so that developers and investors can trade on it. In return for his services the administrator is free to charge a commission for every project funded.

Technical Developers

The technical developer goes to the platform because he has an interesting idea (the next open iphone … ok don’t laugh). He would like to receive capital to open his design, fund the development and make a return. Developers can also go to the platform to join the design team of a project for a financial return.

Informed Investors (aka Informed Consumers)

The informed consumer (note the emphasis on the word informed, this is not your typical “fashionable techie”) goes to the platform with a clear technology need (e.g. an accounting suite or a new computer …etc). He browses the site, purchases shares in relevant projects, proposes changes (add/remove features, finances or return incentives), votes on proposals and receives his return incentive (e.g. his accounting software, computer hardware, technical support …etc).

User Operational Environment

All users initially install the client web application. All major operating systems are supported (GNU/Linux, MAC, Windows). To become an administrator user (i.e. to host a crowdfunding site) you need to install extra plugins/libraries (e.g. hardware crowdfunding, software crowdfunding …etc, Bitcoing Payments …etc)

All users can interface with the web application through a:

Command Line Interface (i.e. terminal/shell interface)
  • Comprehensive support for all tasks.

  • Shipped as part of the core application.

Graphical user interface
  • Support for common tasks (graphical wrapper around shell commands)

  • Supported through external plugins/libraries).

  • Bundled with the client application.

User API
  • Considered for future release.

In the future other client applications (points of entry to the network) can be written to facilitate adoption, for example:

  • Android client app.

  • iOS App

  • Browser add-ons/extensions

  • External plugins to support HTTP access to the crowdfunding sites. (So that users can visit sites directly through their browsers).

Use Cases

The following are the typical use cases for our platform:

An Administrator Hosts a Market Place

A wise yet simple minded individual (e.g. he uses GNU/Linux you see), wants to host a crowdfunding site in his computer so that he can make a hefty return while others can exchange designs and products on his site.

He proceeds to download the application and install it in his Raspberry Pi computer, then he installs the necessary plugins to host open software projects (e.g. software crowdfunding plugin, Bitcoin Payments plugin …etc), finally he contacts his local network of smart friends which start creating projects and trading in the platform at once. Soon money starts rolling in (gonna need a couple of sacks for those BitCoins, … maybe not).

A Developer Creates a Project

A bright unemployed engineer (he is a bit cocky and has poor communication skills) comes with an idea to a crowdfunding site, he would like to create a project to receive funding and work full time on his open idea while making a decent seven-figures income (nudge, nudge).

An electrical engineer creates a project in a hardware crowdfunding site. He follows the site guidelines (builds his requirements, design and financial plan) and recruits a design team. Then he opens his project for investment and negotiates with potential investors to reach an agreement. Development starts and scheduled milestones are met, finally he completes the project, releases the design and delivers the return to all applicable investors (depending on their percent of ownership on the project).

A Developer Joins a Project

A recent grad computer scientist is browsing through the platform to find a meaningful open project to work on (she quit her last job at the book-face.com; too many ads), she would like to join the design team of a project, work full time and earn a living.

An ad-blocker project in a nearby crowdfunding site is currently seeking technical team members. She expresses interest and the creator of the project interviews her, they negotiate potential salary conditions if successfully funded. The programmer is added to the project’s design team, the project is capitalized and the programmer starts working on the product.

An Individual Investor Funds a Project

An informed consumer (again note the use of the word 'informed', not marketing-prey or tv-misinformed) is browsing through the platform, he finds a site hosting an open design which fulfills his needs. He would like to purchase shares to support the project, vote on proposals and use the software application.

A well-meaning design team is currently seeking to develop an open tax platform (tus-botas) to help people understand and fill their taxes independently. An individual investor is very interested on the program, he looks over the user and technical details and purchases a single voting share on the project (e.g. worth $10). Then he launches a board proposal to add support for the form W-2 for his small company (very sneaky), the proposal receives the support of the other shareholders and is added to the requested features, a new project price is quoted for the added effort and investors vote to accept the proposal, the project is developed and the investors receive their tax preparation software (along with a new pair of boots, spanish anyone?).

An Institutional Investor Funds a Project

A money-driven nice-looking engineering manager is browsing through the platform and finds an interesting project that could be integrated to his software application and meet a required feature at a fraction of the cost (outsourcing means bigger bonuses you know).

A manager from Soft & Micro Inc sees an interesting project that could come in very useful as a hand-writing recognition add-on to his 'little' note-taking company software (2-note). He purchases the majority of the shares on the project and votes on multiple proposals to tailor the project to fit his company needs, then he negotiates with the design team and they reach an agreement. The project is completed, released and the engineering manager receives his return and integrates the open functionality to his note-taking software, he receives a bonus and spends it on a new electric car.

An Investor Creates a Project

An informed consumer (either an individual investor or an institutional investor) creates a project with specific user requirements. A technical team takes-on the project, receives funding and releases the application.

An informed consumer has an idea for the development of a fingerprint lock (yes, another smart lock, taking the keys out of your pocket is unnecessary, just imagine how much time you could save). He generates a set of desired user requirements and updates the status of the project to 'seeking technical developers'. An interested design team takes-on the project and continues building the campaign. The project receives funding and the fingerprint lock design is released for production.

Features and Requirements

Discuss and contribute

Use Issue 3 to discuss this section. Your contributions make a difference, no contribution is too small.

The following is a list of features required for the first development cycle:

  1. Support for a decentralized database system (blockchain based …etc)

  2. Decentralized storage (i.e. the schema) of:

    • User credentials

    • Crowdfunding sites reviews

    • Project’s information

    • Project’s Reviews (accountability and transparency)

    • Developer Reviews (accountability and transparency)

  3. Support for pluggable architecture to support extra functionality/plugins

  4. Support for crowdfunding categories plugins (Hardware, software …etc)

  5. Support for payment plugins (Bitcoin, Stripe, Paypal, Amazon payments …etc)

  6. Support for project category tags

  7. Project Search functionality (local and remote search results)

  8. Support for project messaging board

  9. Support for project ownership and team selection

  10. Support for multiple return incentives (Voting rights, support packages, material units …etc)

Postponed/Removed Features

Discuss and contribute

Use Issue 3 to discuss this section. Your contributions make a difference, no contribution is too small.

These are the ideas that will not be implemented. They are too bold, too outside the box, so they belong outside of the application, maybe for the next release cycle (evil laugh). keep increasing this list continuously (i.e. simplifying the application to the bone) so that we can meet our release cycles.

Visual Specification

This section is outdated!

use Issue 5 to discuss and help improve this section. Your contributions make a difference, no contribution is too small.

The visual appearance of our wireframes should be taken only as a reference, meaning the implementation of every page should adhere to what is technically simplest (lowest overhead) and possible (standard practice).

Home Page

The home page is presented to people that access the marketplace site directly from the browser (e.g. by typing mymarketplace.com on your browser), it is the point of access for every general user.

The The home page has the following main purposes:

  • To get people to create new open technology projects.

  • To get informed consumers to search for projects on the marketplace and invest.

  • To allow people to login (or sign-up) to their account and manage their projects or investments.

  • To allow anyone to get information about the specific marketplace and the underlying application (i.e. the Osohm marketplace software).

Wireframe

Home Page Wireframe
For Mobile Devices

The mobile device will have a collapsible header menu (keeping with mobile standards) and it will not have the projects carrousel.

Actionable Items

The general home page has the following actionable items:

  1. MARKETPLACE("Home button")

    Used to direct the user to the marketplace Home page.

  2. LOGIN ("Login button")

    Used to direct the user to the Login/Registration page.

  3. CREATE ("Create Button")

    Used to direct the user to the Project Creation page.

  4. SEARCH ("Search Button")

    Used to direct the user to the Projects Search page.

  5. CARROUSEL ("Latest Open Projects")

    Used to direct the user to the latest relevant open projects.

  6. ABOUT US ("About Us Button")

    Used to direct the user to the About Us page.

  7. FAQ ("FAQ Button")

    Used to direct the user to the Frequently Asked Questions page.

Login/Registration Page

The Login page can be accessed directly through the browser url (e.g. marketplace.com/login register), or from the navigation bar at the top of any page. The login/registration page allows people to register for an account if they don’t have one or login into their existent account (this is pretty self-explanatory right?).

Wireframe

Login Page Wireframe
For mobile devices

The layout for the mobile device login page is simply the inner login window inside the desktop layout (see desktop wireframe below).

Actionable Items

The login page has the following page specific items:

  1. LOGIN("Login Button")

    Used to confirm the user credentials and redirect users to the User Account page.

  2. Stay Signed In ("Stay signed in Check-box")

    Used to save the user session upon login.

  3. Forgot your password("Forgot your password Link")

    Used to direct the user to the Password Recovery page.

  4. Register here ("Register here Link")

    Used to direct the user to the User Registration page.

About Us Page

The About Us page can be accessed from the footer navigation bar or from a direct browser URL. The About Us page allows for all users to read crucial information about the marketplace (e.g. the physical location, contact e-mail and (perhaps) phone number). It also allows the site members to provide a quick Bio of themselves, so that everyone can know they are dealing with the best people.

Wireframe

About Us Page Wireframe
For mobile devices

The layout for the mobile device about us page will have the pictures scaled and placed below the text to fit a one column small-width presentation.

Actionable Items

The About Us page has one optional actionable item: the member can pro- vide a link to his blog/professional profile by providing a link in his/her name.

FAQ Page

The Frequently Asked Questions page can be accessed from the footer navigation bar or from a direct browser URL. The FAQ page allows users to find solutions to common problems they might be having with the platform or general helpful information.

Wireframe

FAQ Page Wireframe

Actionable Items

The FAQ page questions are all collapsible and can be expanded by the user clicking on each question. Only one answer will be expanded at a time.

The collapsible sections will be implemented with simple html/css static functionality.

Search Page

The Search page can be accessed from the home page (search button), from the common search button in any page and from a direct browser URL.

The Search page allows for users to search for projects existent on the platform.

  • Prior to search query: It displays a list with the latest projects.

  • Upon search query: It provides relevant or similar results to help users find interesting projects.

Wireframe

Search Page Wireframe
For Mobile Devices

The multi-column table will be broken into a single column layout (this is standard practice).

Actionable Items

The search page has the following page specific items:

  1. Search Phrase ("Search Phrase Text Box and Icon/Button")

    Used can fill the form and click this button to submit the search query.

  2. Categories Tags("Categories Drop Down Menu")

    Used to select the category (e.g. hardware, software, firmware …etc) to filter projects by.

  3. Project Name ("Project Name Sort Button")

    Used to sort by alphabetical order.

  4. I-note, moreZ, openHardy, Tus Botas … ("Project Name hyperlink")

    Used to go to the respective project page.

  5. Category Tags ("Category Tags Sort Button")

    Used to sort by alphabetical order.

  6. Status ("Status Sort Button")

    Used to sort projects by their current development status.

Create/Edit Page

The create page can be accessed directly from the home page (create button), from the common create button in the navigation bar or from a direct browser URL.

It allows users (developers and consumers) to create projects, by filling in or updating all of the required information for any project.

The content of this page is only displayed to logged-in users, other users are redirected to the login page and displayed a page message.

Wireframe

Create/Edit Page Wireframe
For Mobile Devices

The multi-column layout of the buttons at the bottom of the screen will be broken up into a single column layout (this is pretty standard).

Actionable Items

The Edit Project sections are all collapsible and can be expanded by the user clicking on each section. Only one section will be expanded at a time.

The Create/Edit page has the following collapsible sections:

  1. Project Basics ("Project Basics Collapsible Section")

    The project basics collapsible section will have the following fillable forms:

    • Project Name (Form): Choose something meaningful (e.g. HumanClone).

    • Project Logo- Optional (Input field): Choose an .svg from your computer.

    • Project One Liner (Form): Short and descriptive (e.g. One device, lots of humans)

    • Project Category (Choose Tags): Hardware, Firmware, Software, Manufacturing, Research …etc.

    • Description (Form): One paragraph description (e.g. We are building hardware that will make cloning possible in every household …)

    • Licenses (Drop Down Menu): Choose a License (e.g. GPLv3, MIT …etc).

    • Primary Contact (Form): Initially pre-populated field, can select other registered marketplace users (e.g. to transfer ownership).

    • Location (Form): Physical location of project. City and country available to public, address available to investors after funding.

  2. Features and Requirements ("Features and Requirements Collapsible Section")

    This will be the user requirements document or functional spec doc.

    • User Documentation (one or more URL entry fields).

  3. Technical Team ("Technical Team Collapsible Section")

    This section will allow the owner of the project to add registered team members to the project.

    • Project Owner display field (can not edit)

    • Technical Team Names (text entry field)

    • Add more members (button).

  4. Technical Documentation ("Technical Documentation Collapsible Section")

    This will be the design specification: Starts as technical specifications and as the project evolves this will become a technical design document.

    • Technical Documentation (one or more URL entry field).

  5. Financial Plan ("Financial Plan Collapsible Section")

    The financial plan deals with costs, shares allocation, voting (1 share entitles you to voting participation, more shares, more voting power) and returns (hardware, levels of support, length of maintenance …etc)

    • Costs breakdown (form).

    • Issue shares and price per share (form).

    • Return packages (form).

  6. User Manual ("User Manual Collapsible Section")

    This section will allow the owner of the project to publish a user manual/tutorial wiki for the public to use and edit.

    • User Manual Wiki (URL entry field).

  7. Public Message ("Public Message Entry Field")

    The owner can use this form to provide short public updates about the project (they will show up in the search results.)

  8. Save Project ("Save Project Button")

    The owner can use this button to update the project information.

  9. Preview Page ("Preview Page Button)

    The owner can use this button to preview the project changes he/she made.

  10. Preview Page ("Open to the Pubic Button)

    This button is dynamic. Depending on the current status of the project it can have the following values.

    • Open to the public: Anyone can see the project page (this is normally done after filling the features and requirements section).

    • Launch for investment: This button becomes available after the project is public and the team, technical documentation and financial plan sections are completed.

    • Finish Project: This is normally done after a user manual has been published.

The collapsible sections will be implemented with simple html/css static functionality.
Every section will have instructions to guide the project creator, incentivize good design principles and streamline the process.