On Tue, 13 Jan 2004, Nathan Hurst wrote:
bulia byak wrote:
Nathan, let me respectfully disagree.
...
Can we stop treating this as a commercial project whose main aim is to maximise user base? I've been on such projects before, and they usually die a horrible death.
If a project has managed to gain a good user base, it doesn't already sound like "horrible death" to me, regardless of what lies ahead. Projects that die _without_ users look much more pitiful.
Yes, that's why I want balance. I am saying that making the aim 'lots of users' is bad. You're saying 'making no users is bad'. I'm trying to say "Lets not emphasize user base, rather get things done." This means that if a decision is between more users or easier for developers, I say we take the easier for developers option.
In this case it means using gtkmm _despite_ it not being available in large quantities. In this case it means not holding back a feature because it makes the windows port hard. In this case it means throwing away a large chunk of UI code because it was clumsy.
Otherwise we will decend to the point where all we are doing is minor tweaks to the about box... :-)
Bryce? You've been quiet so far.
Sorry about being quiet... It sounds like the discussion has achieved the right points.
I think it's a good point that while growing the userbase is good, it is to be balanced with other, more important needs. Unlike commercial projects, our source of value (contributions in this case, rather than money), comes from developers and power users.
So when considering dependencies, I like to think about what will make their life easier. Sometimes adding a dependency can do a lot of good, in that it simplifies the code or makes possible features that will make the project more interesting to work on. But the tradeoff to watch is if the dependency causes installation headaches - such as with platform portability. The risk is losing that potential new developer.
I think we've done things the right way in this case. We identified Gtkmm as something we want, in order to make the codebase easier for developers to understand (we hope!), but ran into some package availability issues. We got those issues raised and communicated, and it sounds like they're getting addressed, which is exactly what we hoped for, because in the end this will benefit not only our project but also any other projects that wish to use Gtkmm in the future.
I think folks are anxious to see 0.37 released, so like others pointed out, even if all issues are resolved, we shouldn't plug it in immediately but plan it for one of the future releases. This will also give folks time to doublecheck that the dependency situation really is satisfactory to them, and do some additional testing. The extra time will also hopefully see the dependency become available in a wider range of distros.
I think it pays for us to be very careful in adding dependencies that most folks will have to download. The more steps one has to go through to get an application working, the more likely the person will run into a problem and simply give up on it. I know this is true for me, and I bet everyone here has run into this sort of situation. It can require a lot of fortitude to navigate through such things.
Now to bottom line all this - what it means to us as a group if we have tricky dependencies is that our mail boxes will get full of people with questions about trouble installing it, and we'll have to use our time to explain that, no, they also need the -devel version of that lib, didn't you read the README? ;-)
Anyway, so I think the general concensus is vectoring in to the right position. We want to use Gtkmm when we all are confident it will not pose undue problems to our target audience. We want dependencies that make our lives easier. If they don't, then we want to encourage them to improve so that they will.
Bryce