Time to act

Community
1

Hello fellows.

I know that Haiku inc. have enough money.
What if we start two bounties? For 3d acceleration and for Chrome port (Chromium)?

It is two last steps which will make Haiku accessible for wide range of users. Because all needs modern browser for internet experience. Modern browser requires 3D acceleration. And Haiku is modern OS which needs modern browser. We can’t make it byself because it more complex then Haiku itself…

So we just need announce our intentions for large public and let’s see who will who responds. And then we will choose from the candidates who is best suited.

We must make such public call.
Why not just try? What we will lose? Nothing…

3 Likes
2

Correct me if I’m wrong but porting Chrome is an unrealistic target. Not only they don’t accept patches upstream, keeping up with code changes and maintaining the port would be a nearly full-time job. Resources would be much better spent improving Web+ and therefore Haiku itself.

For 3D acceleration, it’s a valid request, but Haiku developers might have different plans for that, it’s just not a matter of setting up a bounty.

6 Likes
3

I don’t think it is that unrealistic since we can get the same patches of the blink engine from the QtWebEngine port into a chromium port. So we are not that far behind. The actual issue in the way is using the Haiku API for the Chrome UI.

For upstreaming, yes you’re right. They don’t accept patches for supporting ‘smaller operating systems’. The closest thing you can get a new platform upstreamed to them is GN and V8. In terms of actually maintaining these patches, the BSDs are in a far worse position than we are here.

If the ‘money’ was there, I would rather fund 3D acceleration. At least Firefox accepts patches from us.

2 Likes
4

It seems you are talking in a real politician way:

  • using cathy but meaningless lines like “accessible” or “internet experience”
  • presenting your ideas as ultimate truth
  • telling that this is a must and we need to act now
  • deliberately omitting the hard-candy details
  • evade the way for community-decision regarding using community-money
  • suggesting that throwing money on something will just work
  • also suggesting it is not bad to experiment with others money
  • teling we have nothing to lose
  • promoting whishful-thinking as realistic way to do things

So basically “oh look, this thread again”.

4 Likes
5

Our intentions for now are shipping R1. Not adding more 10-year projects to our TODO list such as 3D acceleration or Yet Another Web Browser to it.

Don’t believe me on the 10 year timeframe? Well that’s the time it took to get WebKit where it is now. Why would Chromium be ported any faster?

And, we don’t have the money to pay someone for 10 years. At normal market rate, maybe 1 year. If it’s one of the crazy developers in the existing team ready to work at half-price (at their own will), maybe two years. And I think these two years should be spent in improving the existing software and fixing bugs, rather than adding more features and further delaying the release.

Moreover, at this point we don’t need bounties. We need a long term and sustainable income (recurring donations) so that we can hire someone as a full time developer. Bounties won’t help for the current team: most of us have full time jobs we will not leave for a one-shot payment, but that we could consider leaving for a long-term offer (even at a lower price, at least in my case).

Do you think otherwise? Do you know people who would be bounty hunters? Do they have some knowledge of Haiku? Would they be happy to work with our team and follow our coding guidelines and take the time to reply to our nitpicking code reviews or would they just rush the code in to get their money? Would they join the team in a long term way or move on to the next bounty in another project?

So, yeah, “that post again”. We don’t think bounties is the right thing, and it has been explained many times. We are trying to find someone at Haiku inc with 30 minutes of free time to open a patreon page where we could collect more recurring donations. I’m trying to convince them to open a liberapay page as well, for the same reason. Our larger problem here is that some people in the inc have no time for Haiku for various reasons (either being already busy with other parts of the project, personal issues, or having lost interest). So first of all we should probably get some new members in the inc and then they could get things moving again. Who wants to join?

7 Likes
6

Serious “deja vu” feeling :wink:
Maybe you should write a blog entry about this topic so we can just link to it every time it comes up.

4 Likes
7

I agree that we should strive for another payed contract. But the contract should be for moving Haiku towards R1. In my opinion that means working on WebKit/WebPositive, system stability and hardware support, in that order.

5 Likes
8

IMO the current work with porting QtWebEngine in lieu of full-fat Chromium should be enough for a while. Less effort and presumable more accepting of platform patches than El Goog.

As for 3D acceleration, that unfortunately looks like it will be pushed to post-R1. Kinda forgot what else is needed for R1, though

9

I do not understand why people always ask everything from the Haiku developers, why is there no money pool created for this and them give out the money to external developers?

The Haiku Team cannot be responsible for everything. And with WebPositive we already have more than a pure system actually has to offer.

Mozilla did not come to Be OS at the time either because the Be developer ported it, it was made by other.

Even a google Summer of code cannot fix that too. We need good full-time developers and this costs money.

10

I agree. There are talks about creating a Patreon account, but apparently no one from Haiku Inc. can be bothered to deal with this.

Does anyone realise that Haiku Inc. is a non-functioning body at this point?

There is a reason people start to voice such opinions, and the reason is that there is not enough action from the project management. Haiku is really close to a release after 20 years, and the lack of a driving force is about to spoil this.

There is no motivating force. Developers work on anything except the R1 milestone. Those who start to work on something abandon it halfway. Gerrit is piled up with patches, no one wants to have a look at those patches except 1-2 people.

There is no shortage of Haiku developers. Active developers in AboutSystem window tells me so. But there is a serious lack of motivation. It seems to me that everyone needs to take a leap of faith, and start working towards a common goal, which is the R1 milestone bugs.

Don’t tell me about developers’ free time blah blah. We all know that people can spare some time for the stuff that they care about. At this point, it’s a huge disservice to all the previous developers who worked on Haiku for years, and lied the foundations for today.

Haiku is too big to ignore at this point, and it’s the developers’ (and Haiku Inc.'s) responsibility to the users, history, and the previous developers to ship the R1 release.

Developers reserve the right to tell me to piss off, but my point stands.

2 Likes
11

The core developers base is too small to take care of all things, I think they already have enough on their plate as is it, maybe some small things could be done to help support the core devs to help them out?
A list of "things needed for … " could be useful (as I’m not a developer I can’t contribute to core Haiku, but I could/can support updating libraries etc (which a lot of us could do) to maybe help on fixing some issues?

12

We already discussed this over IRC yesterday. I think you are not right about all this :slight_smile:

Yes, Haiku inc is in a bad state. There are many reasons for that, ranging from the lack of time from the current members, to the way it is meant to operate, which is set so that people donating money cannot get any extra decision power because of it (we don’t want anyone to “buy” haiku this way and make it whatever they want).

“There is no motivating force” is not true. On the contrary, there are too many of them and they are not all working in the same direction. Some people just want an usable OS, some want to experiment with cool technology, some live in BeOS nostalgia. Some want an “R1” without even knowing what it actually means. Some want to work on a long-term project, and for once, do things properly, when at work they are rushed by external factors to put things in production. Some currently want to take care of non-Haiku things they consider more important in their life, which is fine.

So, yes, several of the developers don’t care about R1. That’s fine. No one can force them unless they want to pay for it. Otherwise, no, the developers don’t have any responsibility to anyone but themselves. This may be frustrating at times, but that’s how it is. Moreover, I think you are projecting your own wills into the past developers, current developers, and other users. No, we don’t all completely agree on where Haiku should go, and each of us has a different view of things. There are some things the developers generally agree on, still, and these are on-purpose left rather blurry and unspecified, because they change all the time, as people join and leave the project, and as we move on in our own lifes. This is part of what makes Haiku still a relevant project 20 years after its start: it always managed to adjust to the world around it that way. Not by big revolutions or u-turns, but by small trajectory corrections. Because that’s how you drive a big ship.

How do we move on from there? Just as we did for the past 20 years: take our time to discuss things, see what can be moved forward, what gets in the way. Try to set realistic goals for the near future. Try to get more people involved. Hope that the people in the inc will finally resign and let someone else take care of it, they know it’s the only way to move things forward but somehow they don’t want to do it. Not spend hours sending messages back and forth on the forum and getting nowhere. Fix some bugs if you can. Triage bugs or create more bugreports. Vote for your preferred tickets on Trac. Just bring your own energy to push or pull Haiku a little towards the direction you want it to go.

Eventually, new releases will happen. Maybe it will be R1, maybe it will be a few more beta versions because we’re not happy with what we have. The situation in that area is already a lot better if we manage to reliably ship at least one release per year (even if there are beta).

As for “the project is dying”, “we’re so close to a release” and “we need a leader”, we have had this for the last 10 years at least, possibly more. Yet we’re still here and making progress towards something. For now the goal is managing to ship yearly releases and fixing bugs/stabilizing things. It’s not time for 3D acceleration and other major changes like that. Maybe for the next release.

12 Likes
13

I think your comment is pretty spot on.

Haiku should have a new vote to decide what the minimum requirement is for an R1 release. Because if my memory serves me right, Haiku should have been released by now if we go by the previous vote. Haiku does not support much hardware and it has its bugs and quirks, but so did BeOS.

Define what R1 should contain in a measurable way and work towards that goal.

14

@pulkomandy recently cleaned up the R1 milestone tickets. Here they are.

The current number of tickets is 708; around 300 less than what was resolved between beta1 and beta2.

2 Likes
15

The features needed in the previous vote have been implemented and this enabled us to enter the beta phase for R1. Now we are cleaning things a bit and fixing bugs. No other features are planned for R1 and we don’t want to add more (how would that help getting the release done?).

However, on the other hand you can’t expect the whole team to dedicate themselves exclusively to bugfixing (that would be at the exclusion of things like reviewing pending patches from new contributors and getting them involved, mentoring students in GSoC, keeping things working on their own hardware, and keeping them usable for example with web browser updates).

So that’s the compromise we have now: trying to balance progress on R1 (mostly bugfixing, boring but necessary), keeping Haiku relevant at least for our own use (that’s quite an easy way to self-motivate) and trying to get more people involved and getting them to stay around (both interesting to do and useful, but with the current stack of pending reviews on Gerrit, a bit of an unfinishable task on its own).

So, what are these bugfixes for R1? The complete list is a bit large (close to 800 tickets today, after I moved about 200 to the newly created R1.1 release instead). But we can see a few that matter more than others at the moment:

  • Making the install process less confusing (beta2 showed us that this was a very common problem for our potential userbase, through both reviews and bugreports)
  • Making the web browser more stable and faster
  • Fixing the package manager to be able to retry failed downloads

And I think that’s it for the very minimum. But we will probably fix some other things as well.

2 Likes
16

I’ve seen some developers stating they want to add features. I’m not against adding features as long as it does not hold up an R1 release.

Correct. The problem that many seems to be worried about is that at the moment you are one of very few developers that actually do the hard work. The rest are inactive or doing work that are outside of the R1 scope.

Again, I’m afraid that with such few developers focused on getting R1 released, it can take 20 more years without a clear goal. For example some developers mentioned that Haiku needs good hardware support (iow drivers) before R1 can be released. That is an impossible task with our current resources.

Your work on trying to get contributions in Gerrit commited, as well as bug-fixing and arranging Trac tickets are very appreciated. We would not have to have this discussion if we had more Pulkomandys.

I would like to suggest that tickets in the respective milestones have their priorities reviewed. Especially low priority tickets that are marked as normal should have their priority changed.

17

“I do not understand why people always ask everything from the Haiku developers”, because it is never their money or time or skill.

I have never seen any of these people with lofty goals say they have sent Haiku $1000 and they would like it used this way, I have never seen any of them say they will spend the time editing the docs or writing usable code - that is always the job of someone else.

1 Like
18

I happen to have more available time than others at the moment. But that could change.
I don’t think I’m really more focused on R1 than others. I’ve spent most of my time in the last few months on:

  • The sparc port (not R1 related)
  • Mentoring GSoC students (not R1 related)
  • Improving ffmpeg and intel video drivers (not R1 related)
  • Porting apps to Haiku, mainly http://ace.cpcscene.net (not R1 related)
  • Trying to get old patches in Gerrit completed and merged (not R1 related)

Are you sure you want more people like me? Because my R1 vs not R1 ratio is not better or worse than that from other devs. It just happens that one of my goals currently is trying to cut down the number of pending patches on Gerrit, which means a lot of easy work (from “just click the merge button” to “fix some formatting and obvious problems, and complain to the patch submitter when things are broken”).

Maybe I’m more active at the moment and maybe I picked tasks that are more visible. But there are people working on deeper issues which maybe will result in one single commit after hours and days of investigation and debugging. Have a look at mmlr’s work on the sound drivers. At tqh’s work on the EFI bootloader. Some tasks require a long time before they bring in their results. And because you see me a bit more, doesn’t mean I’m more active. Possibly it’s the opposite, I’m more part of the people arguing about things on the forums instead of writing code :sweat_smile:

6 Likes
19

You seem to spend a lot of time on Haiku and have done so for a very long time. We don’t complain when developers spend time on something that is out of scope of R1. We don’t care about a ratio, we care about the results. Yours is very good.

Very sure.

Trust me, we see them also. mmlr is visible on Gerrit and in the bug tracker where he is doing a good job helping others between his (fairly advanced) commits.

My whole point is that a defined and measurable goal for R1 would help developers stay focused. Such a goal is missing since different developers have given different opinions on Niels’s proposal (and the discussions thereafter).

20

i’m up for it