I've got a problem / question which I want to be discussed in this thread.
Background: I am an entrepreneur and after doing mostly IT and web design oriented stuff for customers during the last couple of months, I now want to start creating own software and sell it on the internet. I love the principles of free software and would like to create FOSS. If you are now looking into most areas FOSS is really not what you want to create if you are going to sell an application which doesn't require any additional support or service to be delivered - so the software itself needs a price and all income is made by selling the software itself. It simply doesn't make sense to release the code from the business perspective - I've got bills to pay; so money matters - not some teenager living in mama's basement.
So here is an idea I came up with to combine both aspects - getting my bills paid on one hand and creating FOSS on the other:
May an application require a library or framework to be created, this library or framework is going to be FOSS immediately under a license like LGPL. The application itself is going to be proprietary until sales go down enough - e.g. a game is mostly sold in the first one to five years; after that the number of sales go down to almost zero - which allows from a financial perspective the code to be released to the public.
How do you think about this idea? Are there problems I might have overlooked? Do you have different ideas?
What about making the source code available to paying customers by request instead of open to the public? Some might argue that wouldn't be open source anymore but there's a million different versions of open source licensing...
Here I see the following issue: Let's imagine I would like to sell a game. In order to buy the product, I would force all potential customers to sign up first - so that I have customer information in a database. After the payment was made, I give access to the source code. Now let's say the customer was some software pirate from Africa or Asia and the person takes the code, compiles it and releases a "free" (= $0) version on the internet. I am not Microsoft or Ubisoft. I don't want my software to phone home - which could also be removed by a software pirate. So there is no way to check who runs a pirated version of the program. Of course I could then try to hunt the pirate down, but I am not Microsoft - I don't have a law department, a football team of lawyers and a $1.000.000 budget to hunt such persons.
In conclusion: I am too scared from the financial/legal perspective to do that - at least at that point. If you are a company like Epic Games and you sell something unique like the Unreal Engine 4, you can do that - there is no way on earth pirating that thing would create any benefit for the pirate - pirating a game based on UE4 on the other hand can create a benefit for the pirate.
Piratism has always been a needle in he ass for software developers, and non-free open source software is surely more pirated than the proprietary counterpart, and that's a challenge of its own to tackle. Depending on the software one could write the code so that to function properly it has to register with a server e.g. to get updates, but nothing would prevent an illwilling user to modify the sourcecode and share an offline copy, or a copy that syncs the updates from one illegal repo and not from your server. But ask yourself this: how many proprietary applications couldn't be pirated because the sourcecode wasn't available?
Adding to the glorious philosophy of transparency master race, one of the points of OSS is that the enduser can make modifications to the code to better suit his or her needs, it's the redistributing part that's usually limited, and to control that aspect you'd need to be backed up by a legal department, not much of a choice there.
Maybe a more pragmatic approach would be to keep as much of the source open as possible, whilst keeping e.g. an authenticity control section proprietary. It wouldn't prevent pirating 100% but surely would require extra hoops to jump through.
I guess, I just try my initial idea: all libraries and frameworks will be open source immediately while applications remain proprietary until their sales go down and become open source afterwards. I guess that's a more open approach than most companies have - Id Software did that with Quake and Doom. I think it's a good approach to contribute to the open source community.
You could also do something like these guys. They contribute to/create all sorts of open source projects and then sell their expertise in these projects through consultancy services.
I think there's plenty of companies that have some sort of open-source business model, so maybe you should try to hunt some of them down and see how they do it?
I haven't seen them but I know that business model.
I've seen quite a lot in the past and for the most part I was really unsure how those people actually want to get paid.
PlayCanvas is one of those. The PlayCanvas engine is FOSS. You can sign up for free to use their online Editor but online storage and support will cost you money. Here is the thing: PlayCanvas is a WebGL-based game engine. You cannot build any bigger or graphics heavy games with it. I also haven't seen a single valuable game created on that engine. They work on it since 2014 - if I recall correctly.
Since I do almost everything (e.g. web design, computer repair, networks, servers, software development and consulting), I want to focus on software development and consulting in the future - web design, computer repair, networks, servers basically pay my bills currently. I was already thinking about doing consulting / on-demand-software-development, but I am absolutely unsure how big the market (especially the demand) for such a thing would be. I know that there are a few bigger companies doing on-demand Java or .NET development. I don't know how that works for other areas like web development or desktop applications - basically all companies doing on-demand PHP build some sort of online shop or CRM.
I think you will find that if you consult for larger companies anything bespoke that you develop for them will be treated as their intellectual property and you wont be free to distribute it.
I guess it would depend of they are buying a product you have made or your time to build a product they want.
I would also like to suggest that Depending on the software one could write the code so that to function properly it has to register with a server e.g. to get updates, but nothing would prevent an illwilling user to modify the sourcecode and share an offline copy, or a copy that syncs the updates from one illegal repo and not from your server.
The idea behind the consulting is to use own FOSS as a portfolio. If customers can see that you are actually able to build all kinds of crazy sh*t, they can hire you based on what they see and not based on a CV which doesn't give any information about the actual skill set of a person. And then of course one would most likely create proprietary software for them.
I'll not create home phoning software. That's also a good USP (Unique Selling Proposition) nowadays since a lot of software is doing that and a lot of users get annoyed about that - myself included. And yes, if someone invests some time, one could create an illegal server or disable that function completely. The only way to prevent this would be to store all valuable user data in the cloud, so that a user is forced to use the legal version. That would be totally annoying for the users, cause a lot of extra complexity on the server-side (worst case: server infrastructure is only required because of that "feature") and would require a lot of work on security and policies. I still think my initial idea is a valid option.
I get that, but in the end do you have product ideas that are marketable, that companies will pay to use, or would your portfolio simply serve as a demo of your abilities?
If you have product ideas why not simpley use a licence such as the CDDL? That way no one can take your source-code and create a 'community' type edition but the company that buys the product and pays a subscription for support and upgrades gets a copy of the source-code and are free to tailor it if they wish? (At least I think that is how you can make money out of some free software licences).
If you don't really have a viable product you are just back to being like everyone esle with a CV albeit you are backed up with a nice demo portfolio.
EDIT: After seaching about for something I knew I'd read on this kind of topic I've found these articles that might be of interest to you:
If you make a killing, remember everyon eon this website as you spend you wealth :-)
Since software I want to develop is mostly focused on private and small business use, CDDL is not a protection. If you don't have a real (trustful) business relationship but automated payment options for almost anonymous (untrusted) people, everyone receiving a copy of the code could simply create a pirate version. Therefore I would like to go the direction of Id Software (developers of Quake and Doom) - they released old versions after their sales went down, so that enthusiasts can study the source code and learn from it.
I guess only having the portfolio is too little. I really want to develop my own stuff. Building something for someone else is more a backup idea.
Thanks for the links. I think I've read those a while ago - sound familiar.
I want to license my stuff under MPL 2.0. Libraries and frameworks will be fully covered by MPL 2.0 and open source immediately. They will be combined with applications which will be licensed under a commercial / proprietary license at first. After a while, when sales went down, I can still relicense the applications under MPL 2.0 and release them into the pool of open source. I don't believe in community versions. I want to have one version of the software. But if there is some bug which a customer wants to be fixed immediately or a problem a customer encounters while using my software, I can offer support and charge for that. I could also create a wrapper component or something which connects the customer's application with the framework - for instance in JavaEE it is good practice to wrap a third-party API instead of connecting it directly to the application. (Let's imagine I have a C library and the customer needs Java bindings for it - no one wants to do that on his own since most Java developers are not familiar with the Java Native Interface (JNI))