I said above that I'd like to show this logo on my homepage for software that is allowed to use it. Because I want to support Haiku and grab people attention to it. Even with a package manager around, that would still be useful.That's not certainly the point, the point is that a logo itself is not a good idea. Besides, once we have an actual package manager, and a repository, most of these problems will be going away, anyway. We could even have our package builder spit out warnings for incorrectly ported software; it already knows if a software has files in directories where they shouldn't be.
The certification guideline could also be reused as a check before accepting a package in the package manager. I'm not sure how our package manager will work in the end, but I think there will be some kind of central repository for packages meeting the requirements ?
Ok, that makes sense. I asked mmadia and he said that it was not going to be Haiku, inc. either. So it looks like the logo can't be an Haiku one, which I find a bit sad for the project not getting anything back from it. I'll keep working on the guideline set, and see what can be done with it later.In the mean time, we should just not advertise to use any non-standard Haiku builds (by hiding them more), and don't actively support them by providing GCC4 only or hybrid packages for problematic software like libSDL. Also, the better our actual releases are, the more likely it is that they will actually be used as a base for software development; if a developer doesn't make sure his software works on a release, it's just a very sloppy developer that should be tared and feathered -- instead of putting the burden to everyone else. If you want to start an unofficial rating/logo/certification program, you'll certainly have my blessing, but it really shouldn't be part of the Haiku project.