I don’t think that’s technically true. The license applies to software as published, while active maintenance is an ongoing service on top of the software. I don’t think any of the currently popular licenses (GPL or MIT style) talk about any maintenance burden on the author. In fact, most OSS licenses explictly exclude warranty etc.
I’m not sure how you understand “freedom to participate”. If I publish software under a software license, then I am not obliged to listen to any requests about it. That is, nobody is entitled to my attention. Instead, other users may fork the project and create their own community around it.
Is this assuming that the open-source contributor has a job, that the open-source project is relevant for that job and(?) that the contributor can work on the software during the job hours. That sounds like a good place to be, but might not be reality for a lot of open-source contributors.
Cant disagree What I see is that there is an inherent strength and resilency of the ‘mass’ of free software available; yet it is hard to analyze it from individual standpoint of either devs, users or programs/code.
Any financial financial system will not really help. My 2 cents come from a data-analytical point of view: Julia simply needs to be more popular and therefore more widely spread and really used. I am thinking of R and Python. If that is given, it will be worthwhile for packet maintainers to invest permanent work and a commercial environment will develop. The commercial environment and integration in business will also make work for volunteer package developers more rewarding. This again promotes popularity etc. Once this cycle is set in motion, Julia is on the winning track…
I just want to point out, that on Packages - Julia Computing DataFrames.jl is listed as curated open source, which i interpret as: juliacomputing is putting some effort into this.
I don’t think that industry adoption really leads to open source funding. If that was true, then R and Python would have adequate open source funding, but by any measure it seems to be far less than adequate. I really think that the only way for open source to get adequate funding is for academic funding agencies to accept the role of academic scientific software of foundational to big science, and have that start to be a reason it gets better accepted and more prestige.
I have to point out, if only to highlight the amazing work that Bogumił and Milan have been doing maintaining DataFrames.jl in their own time – that list does not mean Julia Computing is paying people to develop all those packages. It rather means that JuliaComputing will help our clients use those packages as part of our support agreement.
Having said that, JC’s employees spend a significant part of of their day writing open source code, primarily on the compiler and standard library, but also maintaining or helping with many packages in many different areas. Also, while some of this is as part of our day jobs, a lot of it is also on our own free time, as volunteers, like many of you.
Moreover, JC is still a pretty small company, and we can only do so much. In relation to the entire Julia ecosystem we are very small, and in relation to everthing that needs doing, we are miniscule!
In certain domains that can work. That’s what’s happened with https://pumas.ai/, and that seems to work. But the packages for that are not open source, but really help drive the SciML ecosystem indirectly (since pharmacometrics is essentially a lot of inverse problems on differential equations). Seems like it’s working out.
I wonder what role government could play in something like this? I’m thinking both in terms of funding and in terms of package development/maintenance. It seems that if Julia could become more widely-adopted in government, government would have an interest in ensuring a robust package ecosystem and also shouldn’t mind open-sourcing certain gov’t-developed packages…?
Scientific research is one of those things that a government body can handle better than private industry which can be risk-averse and focused on short term profits. Of course, scientific research may not lead somewhere but that’s why it’s important cos you never where it can lead you to too. This is too risky for private sector enterprises.
Science is not something a “market” can help solve.
One problem with many of these solutions is that you end up with somebody “picking winners”. If the government became in charge of funding OSS, you would then quickly find an OSS lobbying industry, bribery, etc. Sign me up to be a Julia lobbyist though! Sounds like a good (eventually well-paying?) gig
But OSS is different from science. You can have short term profits from OSS projects (and even some research actually). It’s a question of interest. The key here is how to get more companies to realize that investing in an open source project is more profitable to them in the long-term because of the open source ripple effect and because the companies won’t need to do the software maintenance in-house. A dating app for OSS projects and companies may be just the tool we need!
Genius. Big tech already invests in some foundational projects like linux kernel. But for Julia our foundational stuff are not like big tech foundations. It’s closer to consumer. So… tough.
I tend to disagree here: scientific/numerical packages are becoming mainstream as a means of keeping a competitive edge - approach that stock market (and finance in general) participants adopted decades ago. As a simple example, embedded hardware (ARM like) with a minimal os (linux/bsd) and julia on top can be considered an extremely powerful measurement and control device for any sort of industrial application.
It also talks about how to financially support an individual maintainer of open-source projects and conceits that this works well with recurrent support from multiple businesses that directly benefit from the project.
In the case of Julia projects, a business that creates value on top of them might tend to operate on a smaller scale. So it could it better to just hire a developer and have them contribute to the projects as part of their job (in addition to internal development).
I wish it was easier or even possible to do the following: suppose I am working on a research project financed by a grant. In the course of programming the implementation, I encounter an issue with open source package X (it could be a feature request that makes my life much easier, or a small modification that enables a use the original authors didn’t think of).
The maintainers of X are sympathetic and would fix my issue at some point, but if they prioritize it benefits my project immensely. I would then like to donate to their work from project money with the minimal amount of red tape. In particularly, I would not like to pretend that I am buying their services (write a contract, etc), because they may not ask for market rates — again, most issues in FOSS just get fixed without any financial incentives. Also, this is something I cannot plan for in advance in the grant proposal.
Currently it is my impression that with most grants, this is not possible.
Currently it is my impression that with most grants, this is not possible.
Yes, I think in most cases it’s not even possible to use grant money to hire non-researchers contributing to these projects themselves. Not that researcher time is typically micro-managed, but still…
What I see is that there is an inherent strength and resilency of the ‘mass’ of free software available; yet it is hard to analyze it from individual standpoint of either devs, users or programs/code.
My 2 cents come from a data-analytical point of view: Julia simply needs to be more popular and therefore more widely spread and really used. I am thinking of R and Python. If that is given, it will be worthwhile for packet maintainers to invest permanent work and a commercial environment will develop. The commercial environment and integration in business will also make work for volunteer package developers more rewarding. This again promotes popularity etc. Once this cycle is set in motion, Julia is on the winning track…