×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

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.

issuehunt.io/r/indilib/indi/issues/1191
The following user(s) said Thank You: dolguldur, Sonny Cavazos, Daniel DeSclafani
3 years 8 months ago #56315

Please Log in or Create an account to join the conversation.

  • Posts: 527
  • Thank you received: 139
This is really awesome. I would definitely fund a driver for a piece of equipment I had. Would this also work for feature requests? Lots of wanted features. :)

Also, how do you determine if a driver is feature complete/bug free in order to distribute the funds? I wouldn't want a buggy driver uploaded and considered finished.
Last edit: 3 years 8 months ago by Andrew Burwell.
3 years 8 months ago #56331

Please Log in or Create an account to join the conversation.

Yes, this would work as well for feature request. Though at this time, it's limited to INDI only. I need to find a way to perhaps do it with KStars.
3 years 8 months ago #56332

Please Log in or Create an account to join the conversation.

  • Posts: 180
  • Thank you received: 30
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.

Joaquin
Last edit: 3 years 8 months ago by Joaquin. Reason: typo
3 years 8 months ago #56351

Please Log in or Create an account to join the conversation.

  • Posts: 226
  • Thank you received: 88
Does that concern existing third-party drivers ?
3 years 8 months ago #56383

Please Log in or Create an account to join the conversation.

Yes, it's technically any Github issue in INDI & INDI-3rdparty can more or less be funded by IssueHunt.
3 years 8 months ago #56384

Please Log in or Create an account to join the conversation.

  • Posts: 226
  • Thank you received: 88
Is this compatible with GPL ? I'm not a lawyer...
3 years 8 months ago #56389

Please Log in or Create an account to join the conversation.

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).
3 years 8 months ago #56394

Please Log in or Create an account to join the conversation.

  • Posts: 226
  • Thank you received: 88
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 ?
3 years 8 months ago #56408

Please Log in or Create an account to join the conversation.

All contributions would be made under the same LGPL v2 license for INDI drivers. So if someone wants to fix an issue and submit a pull request, it's going to be LGPL v2 like the rest.
3 years 8 months ago #56415

Please Log in or Create an account to join the conversation.

  • Posts: 226
  • Thank you received: 88
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.
The following user(s) said Thank You: Eric, Paul Muller
3 years 8 months ago #56459

Please Log in or Create an account to join the conversation.

  • Posts: 554
  • Thank you received: 138
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.

Chris
The following user(s) said Thank You: Wolfgang Reissenberger, Jose Corazon
3 years 8 months ago #56469

Please Log in or Create an account to join the conversation.

Time to create page: 1.144 seconds