Here's another message on that thread, this one from Andrew:
On Tue, Mar 26, 2019 at 3:19 PM Andrew Dalke <da...@dalkescientific.com>
wrote:
> 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
