Business Models

Get Started. It's Free
or sign up with your email address
Rocket clouds
Business Models by Mind Map: Business Models

1. Dual Licensing (Open Core)

1.1. Main Idea of Model

1.1.1. Software is offered under two licenses simultaneously, one being Open Source.Two software versions can be the same or one is more advanced than open source version.

1.1.1.1. Selling of Optional Proprietary Extensions / Freemium

1.1.1.1.1. This is a submodel

1.1.1.2. Pros

1.1.1.2.1. It is the most common model. Most open source project succeeded with this model in combination with other models.

1.1.1.2.2. It can allow 100% of source code to be open source if both licenses include the same software version. This may be critical for Decide Treatment. TBD.

1.1.1.3. Cons

1.1.1.3.1. Some forms of this model can be not transparent. Additional efforts are needed to make sure of transparency, in case of choosing different parts of software to be not open source.

1.2. Company and Licenses examples

1.2.1. Alfresco / LGPLv3

1.2.2. Zend Technologies / BSD

1.2.3. Cloudera / Apache

1.2.3.1. Proprietary products are built on open source software

1.2.3.2. Harry refers to this using "Software as a service/Saas" model.

1.2.3.3. Wiki mentions this product in other model too "Selling of optional proprietary extensions"

1.3. Elements we can apply

1.3.1. We can keep the basic version open source and build additional features which might be of commercial use for fee.

1.3.1.1. We can make all source code available as open source and use it for 1) development ideas from open source contributors 2) find and fix bugs. We will integrate those developments to the product. In this way the system will be enhanced by the community efforts.

1.3.1.1.1. Decide Treatment Core can be free and available for all people. Additional features, support, customisation, branding, on premise deployment , etc can be provided as additional service. It can be in a package for a fee, or a subscription, or a per deployment fee. It is critical to thoroughly approach separating what should be open source and what additional parts could be provided for fee. It can be only service around initiation of use.

1.4. Applied Model by DT

1.4.1. TBD on Meeting

2. Legend: Name of Model

2.1. Main Idea of Model

2.2. Elements we can apply

2.3. Applied Model by DT

2.4. Company and Licenses examples

3. Professional Services

3.1. Main Idea of Model

3.1.1. Software remains open source, while additions and side services help sustain profitability.

3.1.1.1. Such service as training, support, onboarding, consulting can be commercialised.

3.1.1.2. Such development services as customization, module development, and integrations can be commercialised

3.1.1.3. Another possibility is making available to the public source code only, without the binary code. Customers pay for easily using the software without a technical specialist. They are offered the commercial service of compiling and packaging of the software with executable binaries.

3.2. Elements we can apply

3.3. Applied Model by DT

3.3.1. Decide Treatment is open source and publicly available. Additional services for integrating the system, setting it up, educate the staff, and customise the desease based system is for payment.

3.3.2. Decide Treatment source code is open source and publicly available. Setting up the system in the cloud is for payment: using it on the web. If an entity or user wants to use it for free based on the avalable source code, they will need a specialist to

3.4. Company and Licenses examples

3.4.1. Red Hat / GPL and others for different products

3.4.1.1. Subscription for Enterprise Version

3.4.1.2. Proprietary parts on top of open source base

3.4.2. SourceForge

3.4.2.1. Subscription for Enterprise Version

4. Branded Merchandise

4.1. Main Idea of Model

4.2. Elements we can apply

4.3. Applied Model by DT

4.3.1. This is to work with different hospitals and establish their own brands and customisations. The services can be done with research grants, stipends, or scholarships". And hospital funding/partnerships

4.4. Company and Licenses examples

4.4.1. Wiki

4.4.2. Mozilla

4.4.2.1. They both sell souvenir products with logo

5. Software as a Service

5.1. Main Idea of Model

5.2. Elements we can apply

5.3. Applied Model by DT

5.4. Company and Licenses examples

6. Partnership with Funding Organizations

6.1. Main Idea of Model

6.1.1. Organisations can hire contractor to create a software to be licensed as open source. Alternative is financing software development by grants and funding from organistions.

6.1.1.1. Pros

6.1.1.1.1. Could be combined with other models applied to open source project to be financially sustainable.

6.1.1.1.2. Funding organisations can attract userbase.

6.1.1.1.3. Team has resources to concentrate on bringing value by developing project.

6.1.1.1.4. Can be partnered with more than one organisation. It would lead to diverse userbase, decreasing financial risks.

6.1.1.2. Cons

6.1.1.2.1. Dependence on external funding sources.

6.1.1.2.2. Limitations dictated by funding organisations, which can prevent software from achieving it's goals.

6.2. Elements we can apply

6.2.1. Funding from 1 or more organisations.

6.3. Applied Model by DT

6.3.1. Great suggestion from Harry: "This is to work with different hospitals and establish their own brands and customisations. The services can be done with research grants, stipends, or scholarships". And hospital funding/partnerships

6.3.1.1. TBD on Meeting

6.3.1.2. Harry put it under "branded merchandise" model. I suggest it suits this better.

6.4. Company and Licenses examples

7. Advertising Supported Software

7.1. Main Idea of Model

7.2. Elements we can apply

7.3. Applied Model by DT

7.4. Company and Licenses examples

7.4.1. SourceForge

7.4.1.1. Ads on their website where they sell other software

7.4.2. AdBlock / GPLv3

7.4.2.1. They get money from Google, which ads get whitelisted, while all other ads are blocked

7.4.2.1.1. This model looks more like "Partnership and Funding"