Slashdot Mirror
Ask Slashdot: What's the Best Business Model for An Open Source Developer?
An anonymous reader writes:
I'm interested in creating really good open source software. However, unless programmers have an incentive to work on their projects for long periods, many projects are be abandoned.
There's many business models surrounding free/libre open source software: support (pay for help, or additional features), premium (pay for more advanced software), hosting (pay for using the software on someone else's servers), donation (two versions of the same app, pay because you want to be nice to the developers), etc. Not all of those business models align the interests of the developer and the customer/user in the same way: support-based models for example, benefit developers who introduce certain mistakes or delay introducing features. (In the short term. In the long run, it opens a door for competitors...) Which of those align the interests of both?
The original submission also asks if any of these models are "morally questionable" -- and if there's other business models that have proven successful for open source software. Leave your best thoughts in the comments. What's the best business model for an open source developer?
There's many business models surrounding free/libre open source software: support (pay for help, or additional features), premium (pay for more advanced software), hosting (pay for using the software on someone else's servers), donation (two versions of the same app, pay because you want to be nice to the developers), etc. Not all of those business models align the interests of the developer and the customer/user in the same way: support-based models for example, benefit developers who introduce certain mistakes or delay introducing features. (In the short term. In the long run, it opens a door for competitors...) Which of those align the interests of both?
The original submission also asks if any of these models are "morally questionable" -- and if there's other business models that have proven successful for open source software. Leave your best thoughts in the comments. What's the best business model for an open source developer?
'Really good open source software' doesn't say much. The business model, if there is one at all, depends very much on the audience you target. Enterprise companies will have different incentives to pay you than school kids do. There's quite a difference between making money from the 1000th Flappy Birds clone, or from some financial statistics system that may change a business forever.
Perhaps if your goal is to make a living writing software, get yourself a well-paying job as a developer or start your own closed-source business, and make open source programs on the side without a business model.
To Terminate, or not to Terminate, that's the question - SCSIROB
You choose the one that pays the most money for the least effort.
However finding the model that best suits a particular client and developer is a totally different question and (IMHO) can not be answered without knowing specific details.
---
And a note to the "editor" . What's the point of deleting a clause from the original submission if you only turn around and then repeat it in full, albeit with some additional text saying that the OP also originally asked this clause? Is this some sort of power trip to show that you actually "edited" the submission? Or is it some sort of "style" that demands this slice and dice?
I am Slashdot. Are you Slashdot as well?
Maybe (personal opinion) the best business model for open source software is "service support" for whatever software he develops. But it depends a lot of what kind of software you are developing. If it is a Game it will be hard to try to get funds for support, but if it a software that can be used on the enterprise it may be interesting to offer professional serious support for the one paying a subscription. If your software if targeted to the enterprise it can be interesting to review Redhat's business model.
If your software is more focused on the "end user" (non corporation) you will have to do continuous campaigns for raising money like using Patreon, requesting money goals for new functionality and asking for donations to continue development.
But no matter if it is open source or close software raising money is always a nag.
Does your software serve a market? If not then it really doesn't matter if it's open source or not, right? Because nobody will want to pay for it anyway if it doesn't do anything useful. Figure that part out before you get all bogged down in the details of financial projections.
Don't quit your day job.
An option I didn't see is to consider selling the compiled program, and release the source code for free. People who wants to support your project will buy the compiled version, and hopefully not release the compiled version for free on an alternate mirror (which would would be like pirating). People who care about the source code, and wants to modify it, they can get it for free and do it and compile it themselves.
Has anybody ever tried this model? Indeed, as someone has already said, it depends a lot on the software, but I wonder if it may work in some cases.
Open source = charity. If you like giving away your time for free do open source and pray you don't go homeless.
It sounds to me that you have to separate goals: 1) work as a free lance developer 2) work on an open source project.
Either one of those is pretty easy to accomplish on its own (assuming you're a good enough developer to get hired to do the work someone else wants, or a good enough programmer to write a popular open source project).
But combining the two will be very difficult (not impossible, but very difficult). Being paid for support means you must develop and market a product to someone who is willing to write checks. That alone is a huge challenge. Doing it on your own when your customers will have the source code makes it even more difficult.
AFAICT our profession has evolved. The sole developer doesn't exist anymore, at least not for longer than a project solving a specific problem. That means that the tasks we do as a computer expert vary very much throughout the course of our assignments. Most mundane stuff is automated and the practive of sharing code via the free open source is so commonplace, that most problems can be solved by downloading a lib from the interweb in 5 minutes.
All in all this means, for me, as a freelance developer with strong ties to FOSS, that I bill my hours and let the customer decide with my consultation where I'm best suited to bring in my moneys worth.
I've discovered that simply charging by the hour is the easyest and fairest for all involved in the long run. So that's what I do. I offer to do anything that falls into my wide field of IT expertise, decline any useful help for things I'm not good at and ask 65 - 70 Euros per hour. End of story.
We suffer more in our imagination than in reality. - Seneca
The best business model is busking.
You can practically give away or sell the initial product at cost. But you really make money on services after the initial sale. There is no moral problem here. You're the expert, sell that expertise to help your customers. Sure it opens the door for competition but that's a healthy market. When you restrict or close the door to competition you end up with Windows.
Seriously. "Best business model for an Open Source developer" is like "Best makeup for a mud wrestler". The assumptions of our society and the trained behavior of the customers do not match Free Software ideals. "Open Source companies" surviving on the market do it by crosssponsoring or borderline extortion centered around the viability of some nominally free offer.
So the best "business model" for an "Open Source developer" is to let himself be hired by someone only marginally vested in Free Software ideals. Or try going into politics and change the game. But if you give someone the option to pay what he wants, most will not pay anything, and none of the rest will pay what they would be willing to expend if that was a mandatory precondition to getting the software.
So you'll earn the wages of a pretty lacklustre beggar. The good news is that programmers don't need much more than that since computers have become cheap.
I should know. I make a "living" that way.
You can't say "unless programmers have an incentive to work for long periods" and " benefit developers who introduce mistakes or delay features" at the same time.
OSS might take advantage of the free contributions that developers are willing to give, but that's where the free ends. If you want to create a product that requires more contribution than you can get for free, that's the very part that you need to charge for -- by definition.
There's no "morally questionable" surrounding needing to get paid to give away more free stuff. Welcome to the concept of remuneration and free lunch and mortgages.
So, as a direct answer to your question, you charge for whatever aspect is costing you money to build.
If you get free hosting, you give free hosting. If hosting costs you money, you charge for hosting. It's that simple.
If advanced features cost money to build, the advanced features get charged down the line.
And, if premium efforts are donated, then they ought to be donated at the same rate as the donations that you receive.
In all cases, you don't pay for it. The users pay for it. How much they pay, and for what, is, quite simply, tit-for-tat exactly the same as what you pay for and how much you pay.
By the way, that's the opposite of how most businesses run. It's more profitable to charge more for things that cost you little, and it seems more valuable to charge less for things that obviously cost more. It's also more profitable to lower the costs of the things that you sell a lot, and ignore the costs of the things that you sell only little.
Getting hired by RedHat is by far the best model that I know.
Their business is growing. They pay well. The other guys there are smart, hard working. They change the world.
Smaller companies could be a good situation too, but there is a bunch of risk. Even well-established companies doing F/LOSS have a hard time. Most eventually sell out so they can pay their employees.
There are many F/LOSS-based companies that do the less-than-nice open-CORE model. Basically, the F/LOSS stuff is only good for toys, not for any real use. I'm looking at SugarCRM and at Alfresco. A few years ago, the Alfresco company said an average deployment was $250K - nice F/LOSS - NOT!
It would be hard to find a better situation that was F/OSS related than RH.
IMHO.
Q: How many programmers does it take to change a lightbulb?
A: Only one, but first I need five weeks to undo everything the last idiot did.
That's my business model. Cleaning up after idiots who were using FOSS tools they didn't understand, and whose sins have found them out.
"Pay for help" = bone-headed.
Support is the most expensive thing there is. That is why companies outsource it to call centers in India.
"Pay for additional features" = bone-headed
Just wait until you get an idea of what a customer is going to want for a feature! 4 out of 5 are likely to be nearly impossible.
"I'm interested in creating really good open source software" = triple bone-headed
Why not just say "I wish to live a life of poverty and donate my bones to the Church"?
If you have skills and ambitions, you deserved to be paid for it. And if you don't, it isn't really going to matter what choices you make.
But the first three rules of business are: cash flow, cash flow and cash flow.
And like all prayer, it has no effect on reality and it won't work.
The open source model, as far as income goes, is for those who see "5 minutes of fame" as currency. Basically television babies. It's great if you're educating, or being charitable, or even just showing off. The latter has value if you can leverage an open source effort to get an actual job from someone.
But if income is your objective, the only winning model is to produce something people need, but is so badly documented or organized they can't use it effectively without your support, which you then charge them for. Which is an ethical horror if you do it intentionally, and just an admission you suck at programming, or documentation, or both, if you don't.
I agree with most of the other posters so far: don't quit your day job, or go get one. Otherwise hard times await.
The company I worked for was starting to look for a replacement for Lynx, and I was in the position to choose OpenFire. I wanted to find a host, someone that would offer configuration services and a host for it. I reached out to the various listed supporting companies at the time and got nowhere. I would have been happy to pay someone for a dozen hours worth of configuration support. Instead I ended up setting it up and working through all the issues myself, but that was my least preferred option. There would have potential for ongoing reconfiguration assistance. Eventually we switched back to Office 365's (renamed) Lynx system. That's thousands of dollars I would have been happy to redirect to an open source support company if I'd been able to find one.
If there's a lesson to be learned there, it's that there is money to be had if you can find the demand.
What software you develop will determine what service you can offer for it. What I want to see more of is:
++moderation
I've fallen off your lawn, and I can't get up.
Word Definitions - Open Source.
Means to donate your work to the public, with certain conditions.
Oh -- and you want to paid for it. And probably don't want someone to fork the project and obsolete yours.
There is a definition for that too -- it's called Closed Source.
The obvious answer on how to survive on writing open source is to work for a large company that will pay you to do it. My first thought was:
- IBM
- Redhat
- Oracle
Doing a quick search on who are the biggest corporate contributors to open source software, the first thing that came up was this article: https://www.infoworld.com/arti...
IBM, Redhat and Oracle are also good choices - if you don't want to starve and you understand how the open source ecosystem works, go corporate.
Mimetics Inc. Twitter
on the nature of your customer and the type of software. When you talk about 'business models', before you get into any kind of complicated strategy, the important thing to fix in your mind is that you have to answer this question: where is the cash going to come from?
Let's say your software is a version of Tetris. In that case you don't have many places to get cash from. What you'd do is to find sources of revenue that were so small that it really isn't worthy anyone's time to download the source code from github and build it themselves. Put it in the app store and charge $0.99, or throw up an occasional ad. Just avoid being too greedy, and people will be OK with the bargain. And make sure the app is relatively bug-free, because people will simply stop using it if it frustrates them and there goes your ad revenue.
Tetris represents one end of the spectrum along several dimensions: it is simple in concept and use; it is as non-critical as any app can be. Now I spent a decade as a lead developer in a small company with a product that was the exact opposite ends of the spectra. It was highly complex, took training to operate and administer; had many, many components to install and configure, and was mission critical. This software happened to be proprietary (not my choice, at the time many of our customers had "no open source" policies, strange as that may sound), but the practicalities from the customer perspective would have been the same either way.
License fees were only a tiny fraction of our revenues; in order of size our revenue streams were (write this down): day-to-day technical support, on-site installation and training, software customizations, hardware sales, license fees (in a distant fifth), and finally advanced training. From a revenue standpoint we probably might as well have been open source. There is one thing that being proprietary protected us from: competition. You will have to consider the question of why your customers will turn to you when they could in theory turn to anyone. Competition from other developers is the single biggest problem for any open source business model.
So on either end of the complexity or mission-criticality scale, to make money with open source you've got to be the most convenient way of getting things done. For simple apps, keep them cheap and reliable. For complex apps, you have to sell yourself, and that means being pleasant and professional. If you build a team, don't fill it entirely with grouchy genius slobs; make sure you have people on the team who are young, attractive, and personable too. If you've never tried it, you'll be amazed. If it's just you, well you might not have much to work with, but you should spruce yourself up a bit. Maybe not a suit -- customers will see that as phony if you're not the type -- but maybe throwing a blazer over your jeans and t- shirt will hit the right note.
As for technology, if you have invested a lot of your life in developing a product you'll want to avoid becoming commodity (i.e., easily replaceable) labor after it's finished. That means you need to select your platforms carefully. Avoid the latest "golden hammers" that everyone's learning. Instead look for good projects that make your job easy and have enough of a user base that support won't go away overnight. Think "Scala" rather than "Node.js". Again -- this is from the developer's standpoint. If you're a customer paying someone to develop a system that you will open source, think "Node.js" rather than "Scala".
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Excellent comments by all previous posters! Truly.
Open source is a loss leader in business. It's something you lose money on in order to make the money up (and more) elsewhere. That is hard to pull off for a single person, and tends to be the realm of larger companies with multiple revenue streams they can rely on.
If you want to do open source, I suggest you do so on the side as charity work only.
Print "Hello, World!" *Posts on Github*
As commented in a previous thread, I think that big companies are mostly using open source as a secondary marketing resource. Why not using it as a real technical resource? At the start, perhaps only for innovative, future, R&D projects, but actually-relevant ones. Treating open-source development as the in-house one, by allocating good enough resources to it (e.g., knowledgeable and motivated managers, realistic/adaptable milestones, adequate promotion of new projects, etc.). The prize? Getting a knowledgeable workforce really motivated to deliver the best products possible. And for us, developers? Seriously feeling that our effort might be actually recognised and rewarded (e.g., relevant contributions in different pieces of software or becoming an important part of our CV).
The main problems I see with the current open-source situation:
- Lots of people with low-to-no technical knowledge, even seeing open source as an acceptable alternative to get software developed for free (?!). Virtually no appraisal/recognition. No interest in actually knowing, improving, coming up with the best solutions. Lots of nepotism. Lots of concerns not related at all with programming. Lots of people mostly interested in discussing about abstract issues or not related to the given project/problem/software development. Lots of people seeing it as a forced milestone within their learning/career ("1 contribution to an open-source project. Checked.").
- Companies not seeing the open-source alternatives as a major source to improve/extend their products. They do everything in-house or by relying on their trusted collaborators. There is no feeling of community of knowledge, where only the objective correctness should be appraised; where thinking about the best long-term outputs should be the only concern. There are lots of marketing, HR, managerial, financial, PR, short-sighted, etc. concerns, rather than engineering/programming ones.
Custom Solvers 2.0 = Alvaro Carballo Garcia = varocarbas.
The question is, "unless you're an incumbent megacorp, is holding the source code hostage and relying on lock-in a long term viable business strategy?".
I'm interested in creating really good open source software.
What differentiates "really good" software - open, free, libre, whatever - from all the rest has little to do with the code (so forget about the programmers, they're the easiest part) it is the design, support, the testing, the integration, the documentation, the UI design, the publicity and user-community.
If you want those to be "really good" then none of it comes for free. It is easy to get people to write code. But it is virtually impossible to get a good, free, user interface. The design is drawn out, the focus groups are hard to organise, the features that allow for disabled users need thought and experience, making it cross-platform is tricky and making it intuitive needs a huge amount of talent.
As for documentation. That needs a lot of work by a lot of people. It's dull, often sets the authors at odds with the developers and takes effort to keep up to date.
Add in all the other factors, running a community, testing, integration - and you have little chance of getting anything out of the door by relying on "free" help. So the only workable business model is to make sure you start your project with a great deal of hard cash. Then, when all the work is done and all your life savings spent - then, you will have some "really good" software that you can give away, for free.
politicians are like babies' nappies: they should both be changed regularly and for the same reasons
make open source a hobby.
reality check time.
if you want to get paid (your 'incentive') for open source work... that will be your career goal.. landing the 'perfect' job that does that sort of thing. but you'll need a fucking resume to get it.
Open software's main benefit is the ability to easily fix and customize it yourself, and to make it possible for other developers to fork custom versions. For many professional users, the gratis feature is just a bonus.
So just remove Freedom 0, and use a licence that requires users to pay if they make (production) use the software. Have the source and build exposed, and allow anyone to sell forks, but have the licence say that users of those forks still pay you, while fork developers can charge a premium. Money flows up the fork tree, just like MLM sales.
Enforcement? Most professional users will pay if making the software run in production requires an explicit act such as setting a "Licenced" flag, even if it's easily bypassed, and especially if registered users get better support.
What follows assumes a B2B or B2D (D = developer, which is a unique creature in its own right) product.
Host a multi-tiered version of your open source software. The value add for which people will pay is twofold:
1. The stack from infrastructure to business software is taken care of and presumably "just works";
2. The subject matter expertise required for accommodating advanced or nuanced use cases.
Tier A = Free, Tier B = $[x] per month, Tier C = $[y] per month and so forth.
Release it under AGPL. If anyone wants a more permissive license (that is, if they don't want to release their own source code), then charge them for that.
LZO does similar things, but also has some enhancements over the open source version. The open source version is still very good.
"First they came for the slanderers and i said nothing."
Whatever model you choose, make it easy for the customer to spend their money with you.
Here's a useful trick that I learned. To cut down on contracting costs with larger institutional customers:: use task order contracts. A task order contract is a blanket contract for quantity of future services the customer will request at his own discretion. This solves the problem that there are many times the customer needs a little bit of your time but it's really impractical to contract for $100-$1000 of work. Without such a thing you either end up helping them for free, or they go without your services. Either way you don't get paid.
The contract looks like this:
(1) I agree to provide you with the following services (development, support, training whatever) at $200/hour (for example), billed in fifteen minute (for example) increments.
(2) You name which of your employees can authorize a task.
(3) The maximum cost of a task will be $1000 (for example); if I think the task will cost more than that we will contract for it separately.
(4) The total amount covered under this contract (will be necessary in many cases to specify this) will be $20,000 (for example) and the contract will last until $20,000 have been spent (or until next October, again for example).
(5) Blah blah blah boilerplate that every contract has to have and which makes writing small contracts a financial waste of time.
(7) If you don't like my work you can go elsewhere and you really aren't out anything; on the other hand if you want a guarantee of my availability or response time to a query you will have to pay me a modest retainer.
So the way this works is the customer really wants a report to show such-and-so. He calls you up and you reckon you can do it in ten minutes, plus ten for walking him through installing the changes. So you say, "I can do this for $100." Now if the authorized person thinks this is worth $100, you do it and send them a bill. There is no formal contracting or negotiation required other than go/no go.
The way this *really* works is that since all the tedious and troublesome aspects of agreeing to spend $100 with you are already taken care of, your customers will be included to do it. $50 or $100 here and there doesn't seem like much, but if it's easy to get those little things add up to a lot of money.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
That is how most of the open source is founded outside of mega corps.
Hands $5. Head $10. Tails $15. Full service $20. Every 10th is free. Buy one, get one of equal or lesser value.
An often looked over option is that you can sell the software. There's no provision whatsoever in any of MIT, BSD, GPL, and numerous other licenses against selling the software.
In the event you're selling to consumers rather than developers, it doesn't matter the slightest if you make the source code available. The bulk of your clients either won't know how to install from source, or won't bother if you're asking for a reasonable amount to keep the lights on.
Then the answer is that you're asking the wrong question. Look for a company that writes OS software and work for them.
The odds are really good that if you want to start a business, you're not going to be a programmer. You're going to be a business person.
While it certainly is possible you're one of the very rare folks that wants to and can do both business and program, the odds are against it. And if you're coming here to ask this kind of question, that pretty much seals the deal.
How about offering premium developer support in a 1-1 video conference? There's an app for that... https://bigsmall.io/
There are only two models that make sense. The Patreon model where you basically pay per month or per update, everyone gets the update eventually, so nothing is being held back. The more valuable the software or game, the more organic growth it will have. The other side is the "extended warranty" model which anyone familiar with the software can engage in. E.g. Apache HTTPD. No single developer is responsible for it, but there are plenty of companies and individuals who know it.
I would almost suggest not going the extended warranty route unless you are a Company with 24/7 staff. Nothing is more annoying than having your services down for a week because the kid you hired went on vacation in the boonies.
All of those models work for some projects. For example, MariaDB uses the pay for help (well, actually consulting), web based projects either do hosting or premium - both work. And several smaller projects use donations - mostly with one person "teams", although there are some really big that does this too (wikipedia, for example). Some couple those with selling merchandise and hosting from interested users/companies. And of course you have a multitude of hybrid models - Qt is one of those.
So "the best model" is not the right question. You should go and create something that's good enough for someone to pay money for it. And then figure out what way is the best to keep the project alive. Remember, the users do not pay you. They pay for the software because they think it's worth it.
The FSF will have issues with the moral behind the freemium models because those depend on closed source parts. But all the others should be without issues.
I will tell you this, though: If you approach OSS from a business POV, then you will likely fail. OSS is something you do because you love the code and the project, not to make money. Yes, there are obviously exceptions to this. But they are rare.
Of course, the best known example of the opposite model is the Linux kernel: Create the project, keep running it. But let others do the monetization. Weird model, but it works well :)
I'm not sure if anyone has tried it but perhaps a good compromise between open and closed source would be:
1) Publicly available source code - so that customers have the option to fix bugs or apply patches made by the community
2) Proprietary license - customers pay an annual fee and in exchange get all bug fixes and new releases
3) Short Copyright - after 6-24 months the software reverts to a BSD style license. The term is meant to be just long enough that customers want to pay you for a more up to date version. However, it's short enough that you aren't locking customers in.
4) Free for personal/non-profit use - This is optional but it might make sense to only charge businesses since they have deeper pockets and are less likely to pirate the software
The idea is to try and strike a balance between making people pay you to write code, collecting code submissions for the community, putting together builds, etc. yet still have the code return to the public domain so that people are free to fork it and start an open source project or competitive business.
If you are giving out software where there are limitations to a free version, you are being dishonest if you don't disclose, prominently and up front, what the limitations are. If they involve time bombs or unexpected and arbitrary limits to some functions, this is most important.
It's not right to sucker someone in to using your code, then come back after the person has taken time and labor to adopt it and tell him "oh, the free version can't do all you need, PAY ME". Placing notice in fine print 60 pages into a manual is not good enough either. Notice needs to be early and prominent.
I've seen people's code kicked out of some distributions for this.
If the behavior is disclosed, it's OK pretty much whatever it does. Only the unpleasant surprise is a problem.
I suppose there are some other bizarre things code could do that need disclosure too. Forcing you to, say, swear allegiance to some undesirables like Antifa or the Klan (even with no "enforcement") should be disclosed up front. Asking for personal information can be an issue too. Mut disclosing what will happen mitigates such things.
My favorite form of open source supported projects are dual licensed projects. They have an open source license, but
if you want to compile and distribute a closed source application with them, you need a commercial license.
Example: Do you want to save the world with image processing and Emgu CV? It is open source and free to use.
Do you want to charge people 5$ a pop for the app you make to save the world? Pay a little bit for a commercial license.
I feel like a sucker rising to the bait again, but...
How about if you, as an OSS programmer, prepared a description of the work you are going to do, how much money you feel you should be paid for doing that work, and the criteria by which the success of your work would be evaluated? Then people who want you to do the work could buy "charity auction shares" in your project, and if enough people agree, then you get the money, and afterwards (according to the schedule and budget included in your project proposal), the results would be available to the world. (Don't want to run your own project? A proposal for a larger project should certainly include funding to hire additional programmers.)
Oh! You say you are not an expert in preparing project proposals or managing projects? You're just a good programmer, eh? Well that's why the "charity share brokerage" (CSB) should help with the expertise of making sure that the project proposals are complete and feasible. The CSB would also be responsible for trying to reach prospective donors and for evaluating the results in accord with those success criteria. They should also maintain the website where the donors can look over all the projects they'd supported, see what nice results they'd helped, and thereby be motivated to donate more money for other projects.
This idea differs from all of the crowdfunding websites that I know of by limiting the donations to clearly defined projects and by focusing on accountability and results. The CSB would earn a tithe from funded projects by providing real project management support, whereas all of the crowdfunding websites I've studied just take the money and run away.
By the way, the same mechanism can easily be adapted to handle the ongoing costs incurred by projects that have already completed their development goals. One obvious way is to ask the people who want to use the project's product or service to help donate for the ongoing costs, with special incentives if the current ongoing-cost project expires before the next one is fully funded.
LoDSAUPR, atAJG. However, at this point it would take a bit of doing to convince me that you're sincere, and more doing than that to convince me of your power to implement. I don't think there are many such people left on today's Slashdot.
Freedom = (Meaningful - Coerced) Choice != (Speech | Beer^2), and sad sock puppets' bad mods avail them naught.
Go with the Commission model:
1. Find a problem
2. Get funded by stakeholders
3. Build it on a paycheck.
In terms of the "best" business model, OSS is no different than closed source, in that there is no one absolute "best".
What you need to do is determine what your specific business priorities are and which approach to business is most in line with them. Are you in it to maximize profit? To be able to work on interesting things? To advance a social good? Etc.
Each of those goal has a different "best" model.
If you're like most entrepreneurs, your goal is most likely a mix of things, which complicates the equation, but still the answer to what is "best" entirely depends on your particular motivations.
The open source model, as far as income goes, is for those who see "5 minutes of fame" as currency.
This is simply not true. I know a number of developers who make a good income developing and selling software that happens to be open source. Making a living and OSS are not mutually exclusive.
However, OSS does not make being an entrepreneur any easier (or harder) -- it's hard, and has a low chance of success, no matter which way you go. Nonetheless, there is a noticeable tendency for people whose business ventures with OSS fail to blame OSS for the failure. Odd that when closed-source business ventures fail, nobody blames closed-source for it.
I repeat:
If you have an actual example of an OSS product that is making money and doesn't depend upon bad docs and/or bad code, please cite away.
Whatever personal reasons there is in running a background screening on someone, as long as you are not crossing any legal boundaries, you are free to do so. Here are the most commonly used ways in running an instant background check online.
https://identifypeople.wordpress.com/2017/09/25/a-guide-in-conducting-an-instant-background-check-online-on-someone/