On 2012.09.30 11:20, Hans de Goede wrote: > On 09/29/2012 01:16 AM, Pete Batard wrote: >> The great thing with being a fork is we can afford being unpopular: our >> users have exceedingly easy means to switch away from us if they aren't >> happy. :) > > I disagree strongly here, to me our first and foremost purpose is to > serve our users. Both developer-users and end-users.
I'd like to know how me saying that I don't care about libusbx being popular even remotely implies that I don't want to serve our users. Being most popular != being most useful, especially when you are a contender. The idea that, even for a second, any of the items I am advocating are NOT for the purpose of best serving our users (and yes, both developer-users and end-users) actually flies in the face of everything I have been standing for over these last few years. I thought I had long demonstrated that serving our users is really the only thing drives me. The problem of course is that doing so for the whole group means that any conflicting interests have to be weighted, always. Thus, when you're trying to devise what will serve ALL users best, you tend to end up with the subset of users that may have interests that go against the majority and may fail to see the greater benefit for the whole group. In other words, unless you're not trying, you cannot expect to be popular with everyone. So let me reiterate, in a manner that I hope you will understand better: If being temporarily unpopular with some of our users is what we have to go through to better serve their interests in the long run, then I see it as a necessary evil. And if we weren't a fork, I'd agree with you that displeasing some of our users, even in the short term, could turn problematic, as they wouldn't have other alternatives but to use use our software or develop their own alternative. But we are a fork, and as such, an alternative is always knocking at the door. > But we should try to not make it harder then necessary > for apps to support building against both libusb[x]-1.0 and libusbx-2.0, > by using some configure checks (or some such) + some #ifdef's. We should also try to serve our users best by not leaving any element of confusion as to libusb and libusbx being totally independent projects that will most liklely end up with conflicting APIs, and ensuring that users (both ours and libusb's) avoid having to waste their time on resolving conflicts, which they can easily avoid having to deal with by making a clear choice right of the bat. Yes, this may require them taking some time to evaluate which of libusb or libusbx they want to go with. And this may make flip-flopping slightly more difficult. But I see these 2 points resulting in users wasting less resources overall than they would if we hinted at "concurrent" usage of libusb and libusbx being something we endorse. So that's where I come from. > At least 2 projects I'm involved in, > spice-gtk and virt-viewer both support building against the gtk-2.0 or the > gtk-3.0 API. Again, the issue is that we didn't attempt to exist in a different space when we forked, which is what I'd like us to see us sort here. When you're not trying to address an issue, then yeah, keeping the same header names between 2 versions is for the best. But if there were 2 independent projects generating gtk libraries, I think the gtk deal would change. > Well for our 1.0.x series the goal is exactly to be so interchangeable > for as the apps to just work the same :) Yup. As much as I would like to avoid our users having to solve issues due to 2 independent libraries using the same header and library name, I also expect them not be inclined to choose one on short notice and have to modify their code, so I have no issue going with drop-in replacement for 1.0. On the other hand, for 2.0, which will most likely require apps to update their code, it no longer makes sense. > Anyways if re-naming the header from libusb.h to libusbx.h is that > important to you, It is important to me, because I believe it will avoid our users having to waste time troubleshooting conflicts and being constrained to a lowest common denominator from trying to support 2 libraries. I want them to use their time on much more productive endeavours. Regards, /Pete ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://ad.doubleclick.net/clk;258768047;13503038;j? http://info.appdynamics.com/FreeJavaPerformanceDownload.html _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
