What is stopping you from contributing towards the development of Haiku?

If I had some money I could donate - I would, for sure. I'd probably start donating as soon as I get a job.

There are various ways of contributing to Haiku though. If I had any experience with doing low-level stuff, I'd love to actually work on it and help by writing some useful code.

The only way I can imagine myself contributing to Haiku at this moment would be writing software for it and reporting bugs. I already did some work regarding notification support in Caya, but I guess I need more time and understanding of the APIs to do something serious here.

I personally love Haiku and can't wait to use it as a main OS on my PC. I'm also doing all I can to spread the word about it. Haiku devs - you're awesome!

Not knowing any C/C++/C#.

As for donations: I've no cash to spare. But this system's UI is better than anything else I've ever seen.

I can't code and don't have much money and I don't do any shopping online, if Haiku had some donation cards with a code to type in or some thing then I would buy one.

Personally me the stopper is the overall state of the project. In is completely unfriendly for newcomers. As a developers who have already registered on this site near 8 years ago I want to say following:

1. As the project is marginal is attracts marginal non-professional persons. Of course it is driven by well skilled developers but is is also known that there are some guys who have vote without meritocracy rights to do that. They are just allowed because of marginality of the project. Normally when everything fine usually such people are not allowed to decide what to do. Summary: the meritocracy is not yet reached in Haiku.

2. Second, as a result of first is the development process. Not using GitHub and other social developing basegrounds is totally fail for the project that reduces fun. Attaching patches through web Trac into SVN repository, or even attach patches by email in legacy mailing list kill the fun totally. Summary: please make a development fun not pain.

3. And of course morons in board of directors. I will be concrete and not spare to the whole Haiku, Inc. cause maybe those guys are ok ingeneral. E.g. it is normal for Urias McCullough to call me an psychotic in private chan and depublish my public letter which I hope to see not only developers in mailing list but also a Haiku users about application announcement. I'm not making money on that application, this is not an commercial, but I was banned like I submitting to Apple Store or Windows Store :) Summary: please remove your dicks from board of Haiku, Inc. I don't know how much he does to Haiku, Inc. and the weight of this contribution. But I believe I will be happy without his contribution work.

4. No chances to influence on process. Even bright thoughts are being rejects starting from the discussion. "We don't need it", "here is workaround", any help community tried to provide was rejected on early stages, and I'm talking not about myself, but about other Haiku contributors. Let us remember how long KeymapSwitcher was not included into Image. Also gaps in package management that blocks Haiku update procedure was rejected as unnecessary, despite positive vote in Trac by all developers. Everything said that tools used in process are not working and overall process is broken.

I personally stop donating Haiku project my money and time.
My attempt to contribution was failed and now I will just wait until something changed.
I'm already here for a long time so I have enough patience.
I was trying to be constructive in my remarks about Haiku process,
hope someone in Haiku with cold mind will meditate on it :)

If you're going to continually smear me, you might as well tell the whole story instead of twisting the events and words. Let me reiterate what I said in your article's comments:

Let me iterate what occurred so my words are no longer twisted: You privately contacted me on IRC and asked if I could publish your article, because I was a member of Haiku, Inc. At this point, I explained several things to you:

1. I don't know if we have a policy for publishing articles for community members, and I asked if you could maybe started a thread on the haiku-web mailing list to find out what our policy was.

2. I told you I could (and did) publish the article anyway.

3. I told you that Haiku, Inc. really had no specific control over the website.

Just because I am a board member for Haiku, Inc. (something I volunteered for many years ago, I might add), doesn't mean I am not also a Haiku project contributor. In fact, I was a haiku-os.org website admin before I was ever a Haiku, Inc. member.

I do not regularly keep up with our policies for granting access to other project members to create/edit content on the website, so I was hoping you might ask on the mailing list to find out what the policy was (since it was your article, and you clearly wanted it published).

Now that I have asked you to please not use your article's comments to attack other people and their abilities, and suggested that I regret having published the article, you seem intent on attacking me.

I have no problem saying what I said to you privately in public - your behavior is very psychotic - you went on a tirade in IRC, privately messaging me unsolicited and attacking me directly after I tried to be reasonable about it. I'd be glad to post that publicly, I'm not ashamed.

Do what you want. If the project wanted me to leave, I'd go peacefully - but you are the first person in a LONG time to even suggest such a thing.

@ maxim:
My experience is completely contrary to what you state. Considering the rudeness and arrogance with which you attack the project and one of the most deserving non-coding members, I tend to think the problem is more on your side.
I do agree that the handling of patches in Trac is far from perfect. There are discussions on it on the dev mailinglist every once in a while. The developers are aware of it, but apparently the solution hasn't been found yet.

@ all:
Please don't post angry, you'll feel stupid in the morning...

Regards,
Humdinger

Well, first of all I want to thanks all people contributing code, money and other efforts to Haiku. It's a great Os to use, and a great project to work with.

Yes, we have some problems with getting newcomers involved. Our workflow is clearly suboptimal. But, Maxim, I spent hours on IRC explaining you why we ended up doing things this way, and I still believe the resons are valid:

We had problems with berlios, our previous code hosting service, and we don't want this to happen again. Had we chosen to continue using a 3rd-party forge at the time, we would probably have gone with Google Code Project Hosting. By now, that's mostly a dead-end and we would have to migrate to github again. In a few years, github will lose momentum and maybe we'll have to go with something else. On the other hand, providing our own server is the safer and most future proof solution.

We explained you over IRC that no, you DON'T need to attach your patch to Trac. You can commit your work on a github branch, and put a link to that on Trac. This way, we can work with people that use github (we even have a mirror of our code there), but also with people not using it, and hosting their own git repo, or using bitbucket, or gitorious, or nothing at all and sending patches. If you're not willing to listen to something as simple as this (and you endup ragequitting IRC or something), there's no way anyone is going to take you seriously.

It still seems very unclear to you how the project works: Haiku, Inc. has absolutely no decision power over Haiku. The only thing they can do is pay the bills, and decide wether they want to hire coders to get some code written. So far, no one outside of the developers already having commit access asked for a contract, but should that happen, they could consider it as well. On the project side, there is a known list of people which are considered part of the project. These get commit access, and a vote right when a decision is needed (the votes happen publicly, on the haiku-development mailing list). One thing we vote for is allowing more people to enter the project. We have very high quality standards, maybe too high, because this list of people is what defines the so-called "Haiku way". This is made of things like coding style guidelines, attitude towards problem solving (don't hide the bug, hunt it and squash it), and the general idea of what the system should look like. You seem to understand at least part of this, as you have worked hard to make Haiku Chat match the guidelines and some of the Haiku Way.

As this team of developers get bigger, there are a few unwanted consequences. From the outside, it looks like things are really slow. When you ask them something, it may require a lot of discussion to try to get everyone to agree. If that doesn't work, we resort to a vote. Then we get the results back to you. The process at Haiku, Inc. is similar. You have to also remember (almost) all these people are working on their free time, and in different timezones, making communication even more difficult.

Finally, we currently don't really have someone in charge of the website. The situation on this side is really unclear, and yes, this is something we should improve. We have heard your complaints, and I don't think the general answer was initially "we don't care", but more like "we know there's a problem, but either we don't have a solution yet, or we have designed one, but didn't get it running". We considered using Gerrit as a way to review and approve patches, for example. This would be a very good tool given our workflow, allowing the people with commit access to review patches there, add comments, and approve or reject them. This works well in other projects and has a good integration with git, making it easy to work with. Yet, we don't have people with enough free time and competences to set this up, and it's been on the TODO list for months.

Instead of getting angry at how wrong we're doing things, one way you can contribute is halping with some of these non-development tasks. Editing content for the website is a way to do that. Answering posts on this forum is another. People even became part of the project like this, for example Diver does an excellent work of reviewing tickets, testing apps and finding many bugs, and doing mockups of how the UI could be improved. This is very appreciated by everyone and he is now a project member, including commit access even if he uses that very rarely.

So, the first step in being part of the project is to learn how to interact with others, and try to understand why things are the way they are, and try to improve them yourself where you can. That's the best you can do if you still want to help Haiku.

I would like to see the financial report for 2013 and actual 'money' counter on the homepage before I continue to donate: last time it was updated 1 of December so I don't even know what the situation is right now.

To those dissatisfied commenters from RU-net: you can always fork Haiku and continue developing it the way you like ;)

1 - I got married.

2 - Lot of bills to pay...

3 - Search for my grandfather at Familysearch.org

First off, don't get me wrong, I love Haiku and I do appreciate the long hours you guys spend on it. I'm an old BeOS user so Haiku is its own killer app to me.

Several years ago I decided to give Haiku a real shot at use and possibly contribute since I'm a software engineer by trade.

At that point, you were about to release one of the stable Alpha releases but I can't remember which. After installation, I was stunned at how well it had progressed and I began using it on a daily basis. Other than having to downgrade my video card and a few issues here and there, it was wonderful!

I set up a mirror at home and started to become familiar with the codebase. I've never used jam before, so that was a learning curve, but it was something I was willing to learn.

Life and work schedules prevented me from spending as much time contributing as I would like so it was a few months before I could return and in that time, things broke in the nightlies. This made developing difficult, so I waited for it to stabilize.

It never became stable. Sure, things would be fixed, but then others would break. I waited for newer releases, but those are few and far between so I slowly forgot about it. Now I just check back every six months or so to see how it's going.

As an outsider who has experience with both commercial and open source projects, I'd like to give my suggestions.

Work on more consistent stability in nightly builds. If a user or developer has an issue with the main Alpha release and needs just a few fixes, they are currently subjected to all changes in the nightly builds.

I understand occasional breakage in nightlies, but it's like you're all developing in the stable branch. I can tell you from experience that this is a horrible idea on several levels. It makes getting big fixes to users incredibly hard without also slipping in changes they don't need. It also makes major releases far harder than it needs to be since you're testing completely from scratch each time. Only the directly effected developers should be looking at such unstable commits and checking them into stable once it is fairly tested by a few people.

Stable Alpha releases need to be far more common. You advise against running nightlies, but Alphas are so far apart that users and potential developers have little choice but to run one. Keeping the codebase more stable would reduce your release workload to acceptable levels. If releases take a huge workload then you're doing something wrong upstream.

Much of the work done seems focused on new non-core features rather than stability of core features. I'm not sure how much developer time was spent on package management, but from the outside it seemed like washing a car with a flat tire.

Again, I'm not trying to troll you or be overly harsh, but from the outside there seem to be severe issues with the development process that are hurting users and developers alike.

Thanks for reading.

I love haiku as I loved beos original, I have donated but the lack of wifi driver is the only reason I can't use on my laptop as everyday OS and Ive kindof given up sorry :(

"Contributing" can mean a lot of different things, besides financial support of the project. Some people contribute their time testing the software and filing bug reports, some contribute by purchasing hardware to test Haiku compatability, some write code, and some contribute money.
Since I know almost nothing about code, my contribution is spending money to buy hardware, assembling systems and testing Haiku on those systems, then filing bug reports when things don't work. My bug reports are probably not as good as they could be, since I'm still new to this sort of thing. Hopefully, they will get better as I gain experience and feedback from the developers.
I'm contemplating starting a monthly financial contribution to the project soon, to keep what few coding people we have continuing work on the project.

I agree that alienating the RU-net guys is a really bad idea.

But I don't think that gcc2 is really a problem as everyone is running a hybrid, and if you want software that doesnt build with gcc2 (e.g. qt4 and loads of others) you can just use gcc4, so it really isn't standing in your way. I also dont think haiku is a laughing stock, it seems very well respected by all the Linux and BSD guys I know and as far as I've seen online. And let's be honest, Linux and BSD are systems that were started to be source compatible with other OSs, so it isn't exactly a new thing to be backwards compatible.

You should see the thread on the development mailing list that first suggested that idea! There were some very strong feelings expressed on the matter, with 1/3 of the developers in favour and 2/3 of them against.

@richienyhus

Thanks for that note, I'll have to check that out hopefully later today. Just seems to me, that embedding QT is a huge mistake. I've built embedded operating systems in the past for various projects and I can't even fathom wanting to make any OS rely on a library like QT.

Outside of that I need to free up some time because I do want to see this get further and get better. Worse comes to worse I'll start on extending the layout engine a bit and get some more common controls built out. People like QT because it makes their interface jobs a lot easier, though when the OS Gives you a plethora of controls prebuilt and ready, no reason to rely on another interfacing library to do it. It should be the other way around with the qt library. That's actually one of the points of the QT library anyway; to abstract away different os interfaces and help you port your app to multiple operating systems. It's not a system level api, it's userspace only as well AFAIR.

---- I just read the dev mailing list on the subject.. Either way, its r2 and discussion - so no real impact anyway atm. I would say though, if it's really meant to complete the port of Qt, I would clarify that in the title for the GSoC ideas page. Otherwise people (me or like me) may be confused as to the meaning behind the actual intent.

Here is my contribution:
Two system sounds.
Find the proposed (by me) start-up sound here: http://soundcloud.com/momadezuber/startup
And the shutdown sound here: http://soundcloud.com/momadezuber/shutdown

All in ogg format. Free for all.

Nothing :). I am contributing in making Haiku more usable by applications. Currently I am completing my game which would be ported to Haiku as well, probably first proprietary software made for Haiku. Other than that, in near future I do have plans for a modern Object Oriented BASIC and full(comparable to Firefox?) CSS 3 and HTML 5 supporting Browser (FOSS).

That said, it isn't like I have no complaints. I also disagree with direction of Haiku, I think it should drop all platforms and should move towards x86_64 and Raspberry Pi. Forget about legacy BeOS apps if anything, implement something like emulation layer for old BeOS stuffs for what it is worth.
Haiku development is following the material legacy of BeOS by copying what it was like more than a decade ago? And doing this it effectively cease to follow the spiritual legacy of BeOS! BeOS was legacy headache free, it was most state of the art OS of its time. While in Haiku, we are doing the opposite. Follow BeOS spiritual legacy, we should forget legacy compatibility. Break it, go x86_64 only and implement a SDL 2/SFML based x11 and port GTK2 and GTK3, Qt5, etc. Get all the open source goodies we can, making haiku usable. There is nothing about killing native applications, later we may implement x11 based on Haiku API but until we get more developers that is easier dirty solution. It is vicious cycle- We don't have enough devs = we don't have enough apps = not many people gets interest = we don't have enough devs. If we are able to make Haiku usable, then there are lot of people who hate Apple, left windows joining Linux boat but now bored with Linux/BSD. And many others just giving it a try would love it! Personally if Haiku was even as usable as FreeBSD, I would never install any other OS on real hardware again.

I would disagree that bug tracker is really conclusive indicator of popularity, Haiku community at present is best comparable to PC-BSD community.
Haiku is definately more fun to work upon than FreeBSD, Linux or even Mac OS X. Just need more usable applications :d

I would really love to be able to contribute to Haiku by writing simple programs for the Haiku userland, but the programming tools (at least the ones at my level) are not ready yet, or not sufficiently developed/documented. My skills are not advanced at all, so C++ and the like are out of the question.
I am more oriented towards yab, but I am also looking forward to Lua and FreePascal/Lazarus. The availability of bindings for the Haiku API is ESSENTIAL. Unfortunately, this is an area where a lot of work still needs to be done. I don't have the skills to work on it myself, so I can only hope and wait for someone else to make it happen.
I am sure that lots of other potential developers of apps for Haiku are hampered by the lack of the right programming tools for their level. This does not apply to C++ programmers, of course, but for beginner-medium level programmers the scarcity of the right tools is very much a plight.

I'm just starting with Pootle. Somebody please point to some tutorials, or how to use it properly.

Thanks,

-- louisdem

Humdinger, first of all, thanks again! :)
But I still have a doubt. Do words like NULL, TTY, WHATEVER (capitalized words) -- need to be translated or shouldn't be touched?
Thanks again,

-- louisdem