A great way to get more app developers to Haiku is to port the Haiku API to other OS’es. Gobe actually already did this with the BeAPI, but unfortunaly the source code isn’t available, but it shows that it is in fact possible.
The big hurdle for app programmers is that Haiku is a very small OS and hardly anyone has heard of it so developing Haiku exclusive apps isn’t really an option when they can get way more users on other platforms. But if it’s was possible to really easily to port to other OS’s then they could use Haiku as their development platform making native apps and then port to other platforms without any big hurdle. It’s much better if the apps programmed on Haiku first and then ported to other OS’es than the other way around. This way it dosen’t matter if Haiku is a tiny platform as long as it easy to develop with it and port apps from it.
This solution, combined with finishing porting Wine to Haiku, is a much better way than trying to port individual apps to Haiku.
One problem with Juce is the GPL license of course, but an other much more important is that Juce won’t produce native Haiku apps, it’s way too platform agnostic as I understand it, witch is a problem for Haiku. By porting the Haiku API to other platforms, every app developed will be a native Haiku app and will use all the features of Haiku that other OS’es don’t support and a other big advantage is that already existing BeOS and Haiku apps can be ported to Windows, Linus or OS X easily. Juce can of course be used as an inspiration on how to port the Haiku API to other platforms but it is not a replacement, since it wont be able to make native Haiku apps, if I understand the project correctly.
Just think about all the positive ripple effects of this project, it would make so much more sense if the apps were developed natively on Haiku and then ported to other systems than the other way around. Insted of developers “wasting” time on porting apps to Haiku they could instead develope the apps on Haiku and port it the other way easily. Take gimp as an example, when it was was ported to other platforms it’s userbase increased greatly, the same effect would happen to Haiku apps that are ported to ohter OS’es.
Porting the Haiku API could even bring back commercial, professional softwares (music, video editing, 3D modelling etc…) to Haiku because now they wouldn’t only develope apps for the tiny Haiku userbase but for all platforms at once. With more native Haiku apps that take advantage of Haiku features the more the Haiku userbase will grow.
Im convinced that this could increase Haiku app development by several orders of magnitude so there is no reason to wait since this project will take some time for sure, because by the time as the porting of Haiku API is finished to the first OS, the Haiku R1 should have been finished already. This project should also increase the number of developers that wants to work on developing the Haiku itself since the developers would see that this is rapidly growing OS and that contribution would have a bigger impact.
One thing that is also important, is that it should be easier to develope apps on Haiku instead of other platforms, so a flexible, language agnostic, IDE (like Eclipse) would be a great advantage. The combined effect of these two project would make a huge impact IMO.
With the latest Free Pascal compiler ported to Haiku I am, myself, tempted to start programming again.
IMHO, this would be a wasted effort. Qt would the more powerful alternative for developers that is already available. Writing applications against a Haiku-for-Windows API would offer absolutely no advantages.
You don’t get developers with yet another me-too API. Back in the glory days of BeOS, developers didn’t write BeOS apps to do the same things as on Windows or Mac OS - they wrote BeOS apps to do the things that the other operating systems couldn’t do. If you want to attract new developers, offer something new to them. Not the same old features with a different name.
That’s the reason why they’re already using Qt or wxWidgets. Improving Qt-Haiku or porting wxWidgets to Haiku instead makes much more sense than porting the Haiku API to other systems.[/quote]
If we could port the tab management from Haiku to other platforms as well as the pervasive multithreading that makes Google Chrome so responsive, I think that this would be more of a sucess than QT or wx widgets.
As someone who makes a living writing “commercial, professional softwares (music, video editing, 3D modelling etc…)”, I highly doubt that. I don’t think anybody is going to port their large application to the API of an OS that died 10 years ago and only exists in an alpha version of a volunteer reimplementation. Autodesk put enormous effort into porting Maya to Qt, Vue runs on wxWidgets. The only way of getting them to even remotely consider a Haiku port is to meet them halfway by making wx and Qt available to them.
Anyways, neither BeAPI for Windows nor wxWidgets for Haiku is going to happen unless you or I actually sit down and start writing code.
Many suggestions have been made in this thread for software projects (wxWidgets, Haiku API for Windows, Juce, port tab management, port multithreading). These are all medium to large sized projects. It would be a much better use of time in my opinion if the people who were to write them would instead write five medium to large size native Haiku applications.
New applications come from two places: commercial software and personal projects. I don’t think it’s feasable to make money on a Haiku application, so there won’t be commercial software for now. As for personal projects, they are written by people who have an “itch” they want to scratch.
What can you do you help people become more interested in working on a personal project for Haiku? I haven’t found a good answer yet, but I don’t think having the Haiku API on Linux would entice me very much.
I agree. This has been my experience as I learn the Haiku API and write software for it.
You guys all missed the main, most important point that I was making, the point was getting more native apps to Haiku. Very few is going to write any apps for Haiku with it’s tiny userbase this project objective is to expand that userbase. Very few or any is goin to write those 4 apps your talking about because they know that hardly anyone is going to use their apps, but if we expand the userbase by getting more developers then more native apps will come to Haiku.
Don’t you understand why Haiku don’t have large professional apps? It’s ecause it’s userbase is nearly non-existant in comparison even to Linux. No one is going to write a photoshop rival on Haiku now because it isn’t worth their time, but if they could also port the app to Linux, OS X and Windows without modifications then they would potentionally reach 99% of the all the users. QT and the like won’t bring any native apps to Haiku, but porting the Haiku API to other systems will because then the developers don’t risk wasting time developing an quality app for Haiku that hardly anyone will use.
You’re all naive if you think that developers are going to storm over to a new OS without a userbase and start developing a native office suit, video editor and 3D animation program just for fun. I see this as the only realistic solution to convince programmers to develope on Haiku.
[quote=drcouzelis]Many suggestions have been made in this thread for software projects (wxWidgets, Haiku API for Windows, Juce, port tab management, port multithreading). These are all medium to large sized projects. It would be a much better use of time in my opinion if the people who were to write them would instead write five medium to large size native Haiku applications.
I agree. This has been my experience as I learn the Haiku API and write software for it.[/quote]
I agree that making five medium to large sized application may be a better use of time, but what if you wanted the app on more than one platform. Instead of porting the app to the other platforms, you could just port the one Haiku api.
Imo, I don’t think that the Haiku api would be the same features under another name if pervasive multithreading was included in the port. Haiku api could be thought of as the api that just won’t freeze.
What do you mean by porting API? Build Haiku applications on Linux or Windows or run Haiku application binaries on Linux or Windows? I think first is bad idea: programs will be closesourced and unrunnable in Haiku. Also source compatability is very unstable: some BeOS applications don’t build on Haiku but run on haiku.
You raise a good point, but an obvious solution just popped into my head: it would allow someone who wants to release a closed source application to write the application once, compile it for Haiku, compile it for other operating systems, then release all the binaries.
porting the haiku to other platforms is just a lot of work… with as good as zero benefit. First of all it will be buggy… and it will need a lot of pain. But anyway as good as nobody is writing applications for haiku. You really just waste your time dreaming/thinking how many devs would come to haiku if the haiku api would be available on other platforms too.
The ratio “benefit/effort” is just too small. Even if it would be a “great idea”, there is nobody willing to do it, so it has no sense to continue dreaming… what could be.
It’s like a poor person would being concernated about on what to spend billions, when the day will come and he will have billions.
If you are really think it’s a great idea, and it’s worth every penny, then please go on. Start porting the haiku api to windows. And if you are not able to write code, then download a few books about c/c++ programming… and about filesystems and system programming, start after that porting the haiku api. And if you think you are not able to do that, then go and work and earn money, and pay programmers to port it for you.
Are you able to stand behand your ideas? How much effort are you willing to do? Zero?
That is what you can already do today using Qt. Do you know why nobody’s doing it? Because nobody is writing applications for Haiku. And I don’t see how porting the Haiku API to every OS on the planet would change that.
If you want more applications for Haiku, make Haiku a kick-ass OS. That’s the only reason why people were writing software for BeOS back then - because it kicked ass in a world where every other OS sucked.