This may be true for people with a long background of developping for BeOS, but it's easy to get lost when you start. Having a checklist for beginner developpers will help getting the software better. Sean has been doing a big test run on Haikuware this week and some people seem to be interested in the results. Yes, there will always be badly hacked around software and lazy ports ; but there is also software that can be easily improved. Wether we stick a logo on it or not is another problem. I know I'd like to have some logo to display on my homepage, even if the guidelines are not enforced in any way. I don't think I need the Haiku project developpers to check my app for that ; but I think they should be allowed to tell me to remove the logo if they notice my software is not actually compliant. This may be done by the devs or Haiku, inc; or someone else, but I think it's good to have this possibility, from the haiku side, to keep things under control.Short of moving to an iOS-style walled garden, there's very little that can be done about that. If someone's not motivated enough to do more than a half-assed port involving as little beyond (./configure ; make ) as possible, then the prospect of getting a logo for fixing it isn't likely to motivate them to do it right.Well, was there any guidlines before to prevent the situation ? In much the same way you enforce a very nice coding style, is it not simple to just enforce a few basic tennents and rewards for doing so with the applications?Let the users pressure the 3rd party people, but give them a barging chip.I understand the problem. What you want is some way to tell the good from the bad applications before you download them on Haikuware. There are various ways to provide a solution to this problem. You believe that the Haiku Project setting out guidelines and stamp apps with a logo is going to be the solution. However, that will not work. 1) For any developer who cares how to write a proper Haiku application or do a proper port, it is easy to know what is expected. I mean it is easy to know where files should go and what is expected in terms of integration. I don't think another document is needed.
2) About the logo... it is simply impossible for the project to do this work.Maybe you could spend some tim to think about and write down the things you know that are the "right way" to do. Simple things like using find_directory, having a look at the Interface Guidelines, and so on. Even if it doesn't get any kind of logo to anyone, il can help developpers with less experience to know about what to avoid. I've seen multiple people trying to create /usr/ for a port. For you it makes sense not to have it, but for someone that switched from linux weeks ago it doesn't.There is an easy solution which scales to any size of a software pool: Users themselves rating, commenting and reviewing the apps. For this to work, there needs to be an easy and accessible way for users to do just that. IMHO it should be integrated with the eventual package management and installation solution. When searching for apps, users should automatically find the good ones first. Unfortunately, I don't have time to help implement this, and I certainly don't want to spend time on anything which IMHO will not be a true solution to the problem, like a logo program.
Best regards, -Stephan