Major INDI Library release v1.9.0 bring significant internal changes championed by @pawel-soja to modernize core INDI Library drivers and clients. New drivers for DeepSkyDad Flat Panel & Pegasus devices plus further improvements to PCM8 drivers.
Issue Hunt: A New way to fund INDI Driver Development
INDI community developed numerous drivers over the last 17 years for a multitude of devices. There is still strong demand for new drivers, or modifications to existing drivers. Most of these drivers were developed by community members, and a few directly by manufacturers. I'd like to explore a new way to fund INDI driver development. Feedback is welcome. So at this stage, I opted for Issue Hunt.
There is already one driver partially funded by me as a test. This would give a chance to both community members and manufacturers to support our growing developer community.
Main development should concentrate on new drivers for major devices appearing in the market, documentation (code revision and manuals), and existing-code revision and testing. Code should not break or produce new issues in the client hands after revisions or bug fixes. This, following developers/code engineers internal calendar.
In parallel, a paid development service should be offered for existing drivers and new, more rare/exotical devices under a very clear specifications agreed between client and developer team. This a la carte service could be integrated in the stellarmate gadget cost and should bee clearly differentiated from conventional client support.
I can think on two models of paid development:
- By user request
- By supporting development demands requested by other clients. The client could propose a service itself or bake proposal from other clients. A page with proposals, cost and number of bakers should be created in the new website. Kickstarter-style. Once the calculated cost is covered by one or more bakers, development starts.
It's not related to GPL, it's just a way to highlight an issue and fund it. So if an issue receives enough funds, and there is a developer who can do the work. Then after the developer finishes the work and it gets accepted they receive the funds (maybe there are some fees from IssueHunt in this process as well).
I suppose that, concerning existing third party drivers under GPL, the modified code will be made available to the community after "issue hunting".
Does the Indi development team consider to be the "owner" of third party code it is currently hosting on its github repository ?
Ok, thanks for your answer concerning GPL and availability of paid development for the community.
Now concerning "Owner", as you did not give an answer, let me specify some points.
And start with a short history concerning my 3rd party indi-eqmod driver:
- I started it in 2011, hosted on code.google.com as indi-skywatcherprotocol
- it has been hosted later on sourceforge together with indi as a 3rd party driver, mainly to avoid users compiling it separately
- indi grew up, the forum appeared
There I started to find completely fake affirmations about indi-eqmod. I specifically remember one: "it can flash your camera firmware".
And subsequently confused users asking "Is indi-eqmod the culprit of (my USB hub dysfunctionning or whatsoever)?". I took time
to give an answer and asked the author to correct his affirmation (which he did). One time, two times. I think I gave up with the third fake.
Afterwhile I realized that there was one single author of these fakes, and he was an Indi team member (he "optimized" a small part
of the v4l2 driver that I previously adapted to the Indi CCD interface, and he did that with a direct push).
And this has continued since, convincing users the driver is unsafe/bullshit.
I won't speak about the offensing/pedantic comments in his posts about indi-eqmod.
To sum up the situation is:
- I gently accept my work to be hosted in the indi github repository
- I then read fake affirmations on the forum originating from one indi team member.
- Never other indi team members refute his fakes (if they read them)
- I stopped contributing, being dispappointed by this behavior, just making some updates when you asked me
- I may suppose that my eviction was the goal (in such cases, just tell)
Now comes Issue Hunt: should I left the control of the indi-eqmod driver to a team whose one member has written
fake affirmations confusing non warned users ? As money is involved, this is not the same game.
Let's illustrate with a recent small example: 'Adding support for EQ8-R autohome'
- user comes on the newly created issue dashboard (as suggests a post above)
- 'Owner' creates an entry in issuehunt, 'hunters' wait for the 'bounty' to increase
- one or more of them decide to accept the 'job'
- 'Owner' selects one of these hunters (how ? FIFO, best rated, friend of mine...)
- in this particular case, the assigned developper suppresses the test restricting the autohome feature (1 minute including recompilation)
- user/'Owner' validates the job (how ? Maybe ask the original author)
Clearly I do not want this to happen for indi-eqmod.
I first consider there are other ways for team members to deal with authors who partly helped to build their reputation.
I also consider to still be the owner of the indi-eqmod driver. I don't want to make money with it (go give ascom eqmod) but don't want
others fool people with it. And if you want a situation to change, maybe just ask before bashing authors on forums.
This post will be automagically destroyed in 5 seconds...
PS: it makes me uncomfortable to write this. But things have to be clarified before involving money.
Also note that I'm not against funding open source development this or another way. Just against cheatings.
I've been paid to develop ASCOM drivers. In money and/or in hardware. The peple paying have invariably been commercial manufacturers, not users. In my opinion this has worked well for everyone, the manufacturer and users get a reliable, supported driver and I get paid. Win, win, win. This model makes sense to me, well it would of course, but basically the people who benefit financially pay. I've supported drivers developed in this way essentilly indefinitely.
I'm not suggesting this is the only way to develop astro software. I know it isn't, after all I've also contributed to ASCOM and INDI software with no suggestion that I be paid for my work and I try not to differentate between paid and unpaind development.