On Mar 25, 2019, at 04:05, Francois Berenger <mli...@ligand.eu> wrote:
> Sometimes, I wish there was a rdkit consortium/NPO (so that donations are tax
> deductible), so that rdkit could be massively funded by all its commercial
> users, and even accepting individual donations.
Setting up such an organization is not difficult. It does take time, money, and
effort, which add overhead to the funding process. It also requires people who
are willing to do that sort of work. I was on the board of the Open
Bioinformatics Foundation, and involved with the Python Software Foundation. I
know that I am *not* that sort of person.
In any case, as Geoff Hutchinson points out, there are umbrella organizations
like the Open Source Collective which can handle most of that overhead.
My question is, why would users - commercial or otherwise - be willing to fund
such work in the first place?
As far as I can tell, nearly everyone uses free and open source software
because they are available for no cost. Users are rarely willing to pay for
software freedom, or for economic benefits like avoiding vendor lock-in.
And it seems like commercial users are often willing to use an internal fork of
a project than to work with upstream to develop new features. This might be
because it's easier to work with existing staff or existing contracting
arrangements than figuring out how to get upstream to do the work and setting
up a new contractual relationship, and take the risk that it isn't done to
schedule.
My conjecture is that there are several issues at play.
1) Most end users don't realize there is a funding problem for many FOSS
projects. Package managers like pip/PyPI, Conda, Homebrew and apt make it
*really easy* to install a large number of packages without knowing anything
about the funding or staffing status of each underlying project.
Consider that one of the early business models for PyMol was the idea that
people would be willing to pay for pre-compiled packages from the main
developer, even though the source code was available for free as open source.
That business model somewhat worked then. It would not work now.
2) The proponents of "open source" in the late 1990s emphasized the volunteer
nature of open source, going so much as to argue that there was a "gift
culture" (using E. Raymond's term). The implication is that there was a sort of
social contract, where donations of source code would be met with other sorts
of payment, including job/consulting offers and non-trivial amounts of
reciprocal code contributions.
This has not turned out to be true, with rare exceptions. Instead, I think the
association with volunteerism and gifts has caused people to avoid talking
about fund raising. This should be particularly odd as many volunteer
organizations outside of computing have funding drives.
3) FOSS developers who distribute at no cost are ignoring any capital value in
the software. They can only make income on gifts (which are rare) or through
labor (e.g., consulting). This places them at a funding disadvantage compared
to proprietary software vendors who can amortize labor costs across multiple
sales.
To be clear, I am only talking about self-funded FOSS projects. My paper
mentions a few other funding models, like research grants at universities, or
in-house projects funded by the ability to reduce costs. In the latter case,
the minor additional costs for releasing the project as FOSS can be justified
by even small benefits.
4) The pricing of per-unit sales of FOSS software, either institutional sales
like what I tried with chemfp, or end-user sales like PyMol, should factor in
the likelihood that customers will redistribute the software further, and by
doing so reduce the market size. This factor is hard to estimate, and higher in
general for universities than pharmaceutical companies, which makes it harder
to give a significant discount to universities like what proprietary vendors
can do.
5) In my paper I bring up "free rider problem" as a way to think of the issues.
To be clear, this is only a *problem* if people expect anything back from
releasing and/or maintaining an open source software project. (Or don't expect
people to insist on support, like I have received for the no-cost/open source
version of chemfp.)
Suppose I want to add a new feature to mmpdb, the matched molecular pair
program which I helped develop and has been contributed to the RDKit project. I
might go around to various users and ask for development funding as a
consortium. 20 organizations might be interested, and each one willing to pay
50% of the development cost, which means in principle I could get 10x the cost
of labor, which provides the extra profit that could go towards documentation,
testing, and general support.
However, it's also easy for each of those 20 organizations to think that
someone else ("Let George do it", as the Stanford Encyclopedia of Philosophy
article explains) is going to pay, so why not just wait a year until it's
available for free as open source?
It's all too easy to find one company willing to pay 50% of the cost, and do as
much as possible with that funding. This is the consulting model. This usually
means skimping on documentation and testing, because it just has to be good
enough for that one client. But then it's hard to find funding for the
remaining 50% of the work, because what's good enough for one client is likely
good enough for others, so now only 5 organizations might be willing to pay the
next 50%.
On Mar 25, 2019, at 04:05, Francois Berenger <mli...@ligand.eu> wrote:
> When you think about Linux,
I think that it isn't wise to look to Linux as a source of inspiration for how
to develop free and open source projects. It's one of the "rare exceptions" I
mentioned above.
The Linux Foundation is a trade organization, and its members make money from,
among other things, products which embedded Linux, products which work with
Linux, and (expensive) enterprise consulting.
There is a close coupling between "need to support Linux" and "profit" in that
field. Much closer than the coupling between "need to support RDKit" and
"profit" in this field.
And there are a few billion more people using Linux, so that even 0.01% demand
becomes profitable.
On Mar 25, 2019, at 23:35, Geoffrey Hutchison <geoff.hutchi...@gmail.com> wrote:
> PS One regret is that I haven't had need of chemfp in house, or I would have
> pushed some $$ towards Andrew.
I'm also available for consulting and custom software development. ;)
Andrew
da...@dalkescientific.com
_______________________________________________
Rdkit-discuss mailing list
Rdkit-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-discuss
