need we get a special regular donate to focus on the key?
1st key, the most important debug thing.
2nd key, vote a standard compatibility haikubox to develop its driver.
not only honor , but also real money to prond good developper with Haiku.
should the idea start after R1 release?
or start pre-launching thing for now?
There are many good Dell machines, that are small and have good hardware to use. But then they are not available in every country, or their prices are not what people want to pay.
It is the same for any other brand.
So that is why no âstandard compatible boxâ is easy to choose. In the end, developers will develop for the hardware they use and want to see working.
I you want to hire someone to work on something specific, thatâs not really a donation. Maybe a âbountyâ, or a crowdfunding.
You donât have to wait for someone else to do it. Find someone who can write C++ and ask them how much money they would invoice for these tasks.
if work for capital or sorts of boss, it is evil.
if open source project hire or reward someone to work for the open source project, it only be a efficient way to speed up the progress.
isnât it?
The choice of a recommended platform is a double edged sword. On one hand, it makes it easier to adopt the system for the people interested but, on the other hand, it tends to make people think that other hardware wonât work. At the end, if all devs and users are using this platform only its drivers will be maintained and what was an impression will slowly become reality.
Your first goal is to develop drivers for this platform. This requires someone who has good knowledge of the device targeted and of language used. Haiku specific things, they may learn from docs or comments in the code. Their passion will probably be more focused on hardware. You can imagine someone who worked close to device manufacturer but not tied by NDA. Once the driver is working, they may not be interested to continue with Haiku but instead to make that device working on another system. Depending of complexity and how they documented their code, it can make drivers difficult to maintain. Anyway, for this kind of situation, bounties would be better.
Your second goal is to hunt bugs and improve overall stability. You need someone with a deep knowledge of Haiku and its architecture, probably already a passionate of the OS. This programmer can be indeed hired on the long term and paid with donations.
So, finally, your choice of the platform can turn against you in the long term. You also have two different goals that require two different kind of dev profile leading to two different kind of funding.
how about this wayďź
user can mark the bug with bounties which it want to resolve soon .
it can set a end time or some detail goals.
when it be resolved, the bounties will pay to the developer.
the same bug can be remark by many users.
if one bug get so much bounties to be marked, it be the most important for all people .
for example.
Bug A get 60 Marks.
some of bounties are 10 dollars.
some are 15 dollars, and the other âŚ
the bug can be about system stable or hardware compatibility.
when it be resolved by one developer, all bounties will pay to the developer.
it will be sorts of game which get all people interesting. not only user, but also developer. and it be speed up the progress.
That was tried in the past, but the problem was that most developers werenât really motivated by the money.
all developer donât care about money ?
or just core developers?
are there many normal developers or temporary developers?
company only want money and cut fun.
why open source project only want fun and cut money?
if lots of people get more fun and more money at the same work, it will be efficient. and the project will be more speed up.
core developer will be sorts of saint.
but most of people are not so sanit.
am i right?
i just want to see a voting institution to get fun ă money ă efficient and open source project .
and take them all into combination.
it will be more powerful than corporation.
it be for human.
Dear @Ilovehotdog ,
Your goal is better fit with crowdfunding ( later highlight why, as this topic reappear since I read forum posts without account , or even since I registered here in 2021. This way you got answer for bounties from @nephele about it above - those such bounties are exist anyway - noone had went for them.)
Ok, then enlist the reasons about crowdfunding (and one pain in the ass in this case as well)
â to have the amount of money needed to properly fund at least
one or two knowledgeable people - those matters to hire:
¤ know Haiku enough well
¤ they have enough skill on OS development
(kernel,driver, protocols ⌠any of them or especially more welcomed any of these topics combination as well to find reason of bugs ⌠not only enhancements if that âenhancementâ result not in (a) new feature(s) only, but bug(s), even kernel panics !..)
¤ and ⌠on the top of that good skills
programming in C, C++ language,
programming in multithreaded environment*
(* in this case of course can get help from devs, but how is it if it requires time to get it with sure application in his workflow and understanding and take off the other one from their development time .(It is affordable in case a GSoC student, but for developer who hired to accelerate development (?), hm, at least strange.)
this way comes into picture
¤ existing
and
¤ former
Haiku developers - even back to time to OpenBeos project beginning.
Later I explan difficulties here -
â but also I wish you to not disappointed in crowdfunding.
I admit there is more members here who donate Haiku and/or developers , even monthly as well - as somehow the annual target used to be fullfilled thanks to generous people here.
(Me myself do not lack generosity basically, but I live in a different resource level actually since 2017, so I had not donated any until now - so I kept modest and almost silent about my urgings related to Haiku, but I have also those dreams you can bet on it)
Back on track
This way the project actually has one person contracted.
If we would like additional one or two more developer/maintainer works on Haiku dedicated ⌠the funding goal should be doubled or tripled at lest - but may be more as they might need/want another construction that waddlesplash agreed on in his actual life situation with the board management of the Haiku inc. who employs him.
This way you could help that achievement with a crowdfunding.
And unfortunately I must reveal that pain in the ass,
that comes up
in case crowdfunding âŚ
Actually Haiku is an open source project,
not a product
or
not a commercial,
but a community sevice
this way freely available for anyone who wants to use it.
Free as of usage (if you respect its several licences rules)
and
Free of charge - thanks to the project founders , its goal, and generosity of their developers even on OS or application side.
The Inc. and the licences do not block to establish a firm
to create some product using Haiku (or Haiku itself), but still had not happened.
Also anyone can/could (have) establish(ed) a service related
to Haiku and servicing some conveniency or fundamental to wider the Haiku usage or support for the (discovering) crowd.
Also had not happened widely - however in this case there were an offer recently to some service to publish and/or funding Haiku project better - unfortunately it was not fully fit for the community members. (You can find it, read it on forum if you are enough curios about earlier offers).
So this is about the inglorious hole on the wizardry coat of crowdfunding in case Haiku.
Lastly â about difficulties
to hire an existing or former Haiku developer
to join an accelerating enforcement to a contracted Haiku development team.
¤ some got far away from Haiku or Haiku apps and any reason why they - actually or long time since then -
cannot or do not want to busy with Haiku or any development.
Established a family busy with their carreer - any of it and more âŚ
¤ existing devs have a paid job that is their profession, fit better their interest, pays far more better (think about if their knowledge pays 5-10 times better that the Inc. could offer from this modest annual income : the annual donations)
Also Haiku is just their spare time hobby or love project.
¤ Also consider what Adrien (PulkoMandy) shared with us (he, as he has a paid job, he prefer that he can select/switch between these hobbies, projects by his actual interest - against it he reserve time to support Haiku and progs he develops on it, but he also want to reserve the right to chose on what he works.
¤ Also consider students, who joined as GSoC applicants and some of them still active as developer,
but their main activity is still
visiting the performing rooms,
practice in labs,
or reading materials, books ,
prepare to exams - so education activities mainly.
They cannot contract to support Haiku - at least in actual learning life stadium.
We were in altogether and shared your urgings earlier - at least most of us who passionate and not pragmatical - so most of us were in your shoes.
I can say only our saying in Hungarian translated to English :
*I use bracelet at the words as
¤ without bracelet content of the words - in the translation -
the sentence is word accurate with (Hungarian?) saying
¤ with bracelet content of the words - in the translation -
the sentence is more accurate what is meaning really in deep with (Hungarian?) saying
As those really, faster or slower when it happens.
I have example of it in case Haiku.
¤ waddlespalsh worked on a simpler X11 libraries to support
applications required it - it took longer time in background , and once in a blink of an eye he shared it on forum : example of SLOW
¤ 512 works on many projects regarding mainly graphichs support of several kind protocols and also 2D/3D acceleration areas
besides kernel/driver fixing / improving areas and extend Haiku onto a new platform as well (He is not alone in such wide variety of development to Haiku I just mention it as he participated in this example at this time).
He possibly switching these stuffs so if he works on a development goal he does work on what would be respectful even for a team. so for a fragment of his all available time, you can imagine and calculate it is relatively also long lasting -Once he shared on forum he works on Wayland support in Haiku and showed the results - example of SLOW
¤ menwhile Haikuports members and new contributors regarding the project contractor also had not sit meanwhile, so POSIX compatibility emerged, RAMFS refactored and new libraries ported, and these slow development processes had good news : these altogether once meet and results concluded
into bunch of new browsers and other Qt or GTK applications which went out and now we can see : a known youtuber offers Haiku as daily driver âŚ
showcasing - now yet really rather experimental shiny-tendy eyecandies
even like a trendy game is possible ! example of FAST
And it is good as is !..
I suggest to remain at Haikuâs fun part ⌠as you share your adventures on a small test config, me also shares my experiencies on a badly hurted Haiku install, where native apps mostly works - agains that.some factoring damaged BFS and USB disk errors
Now as Iâm writirg this forum post I can listen fantastic music on StreamRadio meanwhile.
Previously in the week I installed all screensavers and probed them and also launched all Demo apps to do not state silly things regarding (re)sizeable and non-(re)sizeable replicants on Haiku,
that I shared on Haiku screenshost thread when someone complained about small replicant on a 4K monitor. Mostly there is solution for (re)sizing a replicant - the most hiatus is Clock demo app - especially as those who developed a large or sizeable (floating) non analogue clocks - do not share it on HDepot or elsewhere.
However I saw at least 2 of it on screenshots in forum posts !
:shiny_eyes_fan_face_with_saliva: [ as this emoji still does not exist}
(Just right now dragons flies in the sky with a happy queen and dragonfire burns ships, slavery to ashes
I would hear also when dragonfire tracks Kingâs Landing to turn it to fancy ruins by a raging Targaryen and due to a hard hearted, proud Lannister :)) )
EDIT : fixed typos :)) as usual
I can only reply for myself here.
I worked full time for Haiku for a year and it was great. But in the end, Haiku inc ran out of funds, and I had to find another full time job.
Now I work that job and I like it as well. At least, enough that I donât want to quit it to work for Haiku for just a year, and then be looking for another job again. Working for a company gives me safety and stability that I wouldnât get otherwise. It allows me to get a loan to buy a flat to live in, instead of renting one.
As a result of this, I work on Haiku in my free time. Since my full time job is well paying, I do not need any more money. So, yes, Haiku is a âfor funâ project for me. And if I wanted to switch it to a âfor moneyâ project, I would do it only if it allows me to leave my current job and work full time on it. And to do that, I would prefer that Haiku inc has a lot more money than they have now, so that they could hire me in the long term.
There are other developers in different situations, for example, in the past Haiku inc had contracts with developers who already work as for-hire software contractors, for them it was no problem to work full-time for Haiku for a few months, and then move to another customer when the contract ended. And maybe come back later.
So the idea is this: try to give the money to people who will really benefit from it, so that it really enables them to contribute more to Haiku. Each of us has a different definition for that. For me, it would be something safe and long term like my current paid job. But other people may have more short term needs, or be willing to work on a shorter term.
Now regarding âbountiesâ: the idea of bounties is a developer gets the money only if the work is completed. This creates a variety of problems: maybe there will be some unexpected problems and the work will take 10x more time than expected. Then, what was an acceptable pay for it becomes way too low. Maybe two developers will end up working on something, and only one will claim the prize. What will the other developer think? Maybe that other developer did all the difficult groundwork, and the one who claims the bounty only made the last final few steps. Is that fair?
So thatâs why the current system was put in place: people donate to Haiku inc, and Haiku inc pays the developers, leaving the developers somewhat free to decide what they work on (not completely free, but so far the hired developers were part of the core team in most cases, and so, there was a high level of trust between the irc and the contractors). This allows to handle things in a way that protects the developers from drama and incidents, and also protects their personal info that they donât necessarily want to share (for example, if a developer has to interrupt their contract due to health issues, we donât want that to be all detailed in public)
any result should be checked by core team.
then, they can vote the best one to get the money.
it can be setted a frozen time for voting.
if the bounty is too low, the bug may not so important.
then, all developers can do the speed as before status.
and focus on the more important bug which all people vote with bounty.
That means someone may have spent months working on fixing a problem for a bounty, only for someone else to get there first and get all the money.
Personally, this is not a risk Iâm going to take. Not only for my personal finances, but also because it creates a competitive way of working. Instead of sharing code early and working together, people will keep their code secret until it is ready so no one else joins, and it is clear who gets the bounty.
Really, not a game I want to play.
This has an additional problem: sometimes, some not very âflashyâ work must be done to prepare for things. Maybe think of GCC updates. Fixing compiler warnings. Updating 3rd party libraries. No one is going to pay money for that. So, the developers will not work on it, and generally the code quality could degrade.
In my paid job, which is not bounty based, there are some layers of âprotectionâ between the customer demands and my work as software architect. So, when I say that we must spend time cleaning and refactoring code, the team can actually work on it. The customer isnât always happy that we donât always work on new features or even bugfixes for bugs that impact production. But the codebase remains relatively clean and manageable. If I only got paid for things that the customer wants to pay for, I would not be earning as much money.
if the bug need so many time to fix, then the bounty should be much more. any people can decide just to work for the much money or take it as a âthe icing on the cakeâă
i believe all people have the enough mind to decide , to vote or other thing.
just build a institution for voting.
not only user , but also developer.
if one bug is too hard, or it is a system thing, any developer can build a little team to fix it.
and, the core team should describe the detail of the bug.
then , the user will know it is system thing, need much more bounty to run the team working.
or some bug are relationship.
the core team should describe it.
all thing, it just take a real freedom to vote , to work , to decide.
That is not the problem.
Imagine two people decide to work on something.
One of them finishes first. Their work is accepted and merged and they get the money.
Another worked on the same thing, but now they donât get paid because someone else did it first. They spent as much time, possibly more, but they donât get any money.
How do you avoid such situations?
any bug shoud be ranked by core team and get the public frozen time.
if the bug get the A Randed, it should be 5 or 10 frozen days to wait the possible other developer.
if the bug get the F Randed, it should be 1 or 2 frozen days to wait the possible other developer.
then, if no more other developer, the result is good when the core team check, the person should get all money.
if there are other developer fix the bug in those frozen days, the core team should compare to a better one.
the better one get all money.
if both are good , the core team should share out the bounty to the both good guys.
the core team can decide to use any code of them. or combine them into a better one.
it depends on their skills.
Sounds like you would incentivize duplicate work, doesnât make sense to me.
no, it should display who are working to fix the bug.
any people who want to do a competition with the man who already work for fixing bug, the guy can join.
i believe anybody have enough mind to decide to run a competition or not.
just open the information and build the voting institutionă
And then the core team has to do al this work instead of working in the OS.
Also, people will rush to complete the task to get the $$, instead of discussing the better ways to fix, or change it, or whatever. Again, not contributing to quality.
If someone wants to organize the payment to port/fix things outside of Haiku because they want it ( say, to port app X ) , then it´s ok. They will raise the money, find someone interested, and there will be a contract between them and this person. All done outside of Haiku, using just some orientation from the main team ( and knowingly taking the risks of their contribution not being accepted / someone beating them to it , for free ) .
quality decide who get the bounty.
no, the core team will be the controller , sorts of OS-kernel.
no, inside of haiku.
Sounds like a bad plan. Decentralization is whatâs needed. Not just âone throat to chokeâ.