Would you like to be part of something where you have a vested interest in the growth of the product?

We are working on a development model where developers can receive a portion of the profits if the site becomes popular. This is a new concept for us, and we are hoping to get feedback and develop a framework for future projects. The article below explains the concept. If you are interested in collaborating with us, please send an email to info@kartech.com

Shared Source Business Model

Create Date: 08/18/2022

Summary

This is a business model for developing software applications using external developers and resources who provide their service with no upfront cost, hoping to receive a percentage of the profits when the application is released to the public. If a company, organization, or individual (product owner) has an idea for an application, but they don't have the resources to build it internally and can’t afford to hire a company to build it, they can use this model to come up with a team of developers who can work on their project, and in return, the developer will receive points that will be used to determine their percentage of the net profits when the application is released.

Points

The heart of this system is the points model. The points are an arbitrary number assigned to each unit of work based on the estimated amount of effort and value to the project. The points are awarded to each resource after their task with approval from the product owner. When the project goes live and starts generating revenue, the net profit percentage is divided by the number of points, and the revenue is paid to the point owners based on the revenue schedule. Points are paid on the revenue cycle for as long as the application exists.

As new features and enhancements are added, more points will be added to the pool, diluting the revenue over time. Resources who worked on the project and stopped contributing will still receive payments for their points, but their percentage of the net profit will go down.

Creating The Project

The product owner for the application will need to create the project. The project will include the following sections:

• Summary
  A summary of the project is needed because this is what the developer will see first when looking to participate in the project. There must be enough information to attract the developer to look at the entire project. \

• Description
  The description needs to detail that application as fully as possible. A complete narrative of how the application will be used, permissions structures, stored data, and UI mockups are necessary so developers and other resources can understand the scope of the application. \

• Net Profit Percentage
  The payout to resources is based on the net profit from the application. The percentage is the offer from the product owner, with a minimum of 20%. In the case of a business or organization, the accounting will need to be maintained and open to audit for the costs and revenue associated with the application. If the application is maintained by an individual or is the sole revenue stream for the business, profit and loss statements will need to be provided, and tax records will need to be made available in the case of a disagreement with the point owners. \

• Minimum Points
  For contributors to a project to start receiving revenue payments, a minimum point level will need to be achieved. \

• Platforms
  Developers and designers have different skill sets, so you need to make sure the platforms you want to use are defined, so you get the right developers and that each developer knows what language or framework they should be programming in and what kind of architecture the application is going to run on. \

• Features
  Features are at the top of the development hierarchy and define a set of functionality. For example, your application may have a User Admin feature that includes a login page, profile page, and a reset password page. The feature is the top level and is written to cover broad topics. \

• User Stories
  The next level below feature is the User Story. This describes each piece of functionality that makes up the feature and is a unit of work for the developer. In our User Admin example, a User Story for the login page might look like this: “as a user, I would like to be able to enter an email address and password to login to the application.” The user story will also have additional details like a description, testing scenarios, estimated and actual effort, and a point value (see points section below). \

• Tasks
  Tasks can be development tasks that make up a User Story, or they can be non-development work that can be defined and awarded points. A complex user story could be broken down into several tasks where the points are assigned based on each task and then rolled up into the user story. Non-development tasks include graphic design, infrastructure design, testing, administration, and coordination. Each task can be awarded points just like the developer user stories. \

• Bugs
  A bug will often appear after a User Story or Task is complete. If possible, the original resource should work on the bug and fix it, but if the resource is no longer available or it makes sense to keep the person focused on their current task, a bug can be created as a work item with its point value. This can be a valuable tool for maintaining a project because many developers are very good at handling break-fix issues but aren't as good at developing greenfield features.

Putting together the project can be very difficult and time-consuming, especially if the project owner doesn't have any technical knowledge. This may be a function that a project owner would assign as a task to a technical analyst in exchange for points on the project. The project owner must participate in the process and approve all project definitions. The points are awarded if a task is approved, and further updates will require a new task.

Resources

There are several levels of resources. When a project starts getting resources working on items can be done through communication and helping with tasks that get the project organized. A product owner can make a person a core resource after they show they can complete tasks and are committed to the project. The next level is an authoritative resource. They can vote on point values for tasks and approve submitted items before the product owner sign off.

The resource levels are listed here:

• Contributor
  A contributor is a resource who submitted a task that has been approved but hasn’t achieved enough points or hasn’t committed to the project with enough regularity to become a core resource. Resources at this level can work on open tasks. Still, they aren't assigned to them, so it's possible several resources can work on the same item, and only one submission will be accepted and awarded points. \

• Core
  A core resource is someone who has met the minimum point requirements and has submitted the required number of tasks regularly to the project. A core developer can take on a task or user story, which will be assigned to them exclusively until an agreed due date is reached. If the resource misses the deadline, then another resource can take over the task. Deadline extensions can be negotiated with an authoritative resource, but a good reason is needed for the extension.
  
  An authoritative resource will often ask core resources to participate in additional functions that help guide the project. These could include things like being involved in design meetings, code reviews, and testing, and they will include additional points being awarded. \

• Authoritative
  An authoritative contributor helps manage the project and interfaces directly with the product owner. An authoritative contributor can assign and change point values of tasks and extend deadlines for core resources. An authoritative resource will also schedule meetings, code reviews, and testing sessions and coordinate with end users. An authoritative resource can also determine project pivots.
  
  In larger projects, multiple authoritative resources will work together with some approvals requiring more than one person to approve. The product owner is always an authoritative resource with the power to approve all aspects of the project.

Linked Applications

Using this model will require several applications to track the software and the tasks. Below is the list of integrations.

• Custom Site
  A custom site will be needed to maintain access levels and track point values. This site will also provide a listing of projects with their summaries. This will be the central hub that allows resources and product owners to interface with each other and link to other applications. \

• Git
  Git is the most popular source code repository and is the perfect place to track code and provide content integration and deployment services. Github has a solid API infrastructure that allows integration with their site so the custom website can access repository information on projects and make the solution look seamless. \

• Project Board
  There are several project boards for tracking tasks and issues. The question is always whether to build or buy. Both Trello and Jira from Atlassian integrate with Git so they may be a good option. \

• Payment System
  How to track net profit and pay resources is a big question that needs to be addressed. If this model is only used as a one-off for a specific project that can be negotiated with the resources, but if this becomes a platform that links project owners with resources, the payment process needs to be solid. \