Re: [Inkscape-devel] Using gtkmm in inkscape
Nathan, let me respectfully disagree.
Jon, we _DON'T_ want lots of users just yet. Look what happens when you get lots of users: they complain about features not being available;
Which is valuable. We cannot invent everything.
they complain that the interface isn't exactly like their favourite program XYZ;
Which is valuable. We cannot know all existing programs inside out, so why not use this help.
they clutter mailing lists up with questions answered already in the FAQ or user manual(which we haven't even written yet);
More incentive to write it. Or would you prefer writing to a nonexisting audience? This sounds like a perversion to me :)
and you spend the whole time worrying about fixing code to compile on borland visual gcc 2.96.
First, _users_ don't usually tweak with compiling. Second, just set a standard set of requirements/platforms (what you are doing now) and don't care about everything else. And third, it's just as likely that someone will come up with, "Hey, I know you don't support it, but I managed to compile on XYZ, here's the patch."
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.
_________________________________________________________________ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=dept/bcomm&pgmarket=en-ca&RU=http%3a%2f%2f...
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.
njh
Nathan Hurst wrote:
In this case it means not holding back a feature because it makes the windows port hard.
That's "build", not "port". ;-)
I agree.
Hey, I was able to add gtkmm to the windows build -before- anyone else!
Yeah. I don't care about "hard", but I DO care about "impossible." I really think dependencies should at least be discussed before we tack them on. Maybe the the person requesting inclusion of the lib should do the investigation.
We also need to see if a given library is really needed in its entirety, or if only a small portion of it is being used.
Bob
The big question: Should we then add our GTKMM items back to the roadmap for this release?
Jon
On Tue, 2004-01-13 at 07:41, Bob Jamison wrote:
Nathan Hurst wrote:
In this case it means not holding back a feature because it makes the windows port hard.
That's "build", not "port". ;-)
I agree.
Hey, I was able to add gtkmm to the windows build -before- anyone else!
Yeah. I don't care about "hard", but I DO care about "impossible." I really think dependencies should at least be discussed before we tack them on. Maybe the the person requesting inclusion of the lib should do the investigation.
We also need to see if a given library is really needed in its entirety, or if only a small portion of it is being used.
Bob
This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
No, but we should add a task to re-examine the situation for the 0.38 release.
Bryce
On Tue, 13 Jan 2004, Jonathan Phillips wrote:
The big question: Should we then add our GTKMM items back to the roadmap for this release?
Jon
On Tue, 2004-01-13 at 07:41, Bob Jamison wrote:
Nathan Hurst wrote:
In this case it means not holding back a feature because it makes the windows port hard.
That's "build", not "port". ;-)
I agree.
Hey, I was able to add gtkmm to the windows build -before- anyone else!
Yeah. I don't care about "hard", but I DO care about "impossible." I really think dependencies should at least be discussed before we tack them on. Maybe the the person requesting inclusion of the lib should do the investigation.
We also need to see if a given library is really needed in its entirety, or if only a small portion of it is being used.
Bob
This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
That's good. That way we can have a solid release without new DEPENDENCIES for anyone using older systems.
Sounds good.
Jon
On Tue, 2004-01-13 at 10:40, Bryce Harrington wrote:
No, but we should add a task to re-examine the situation for the 0.38 release.
Bryce
On Tue, 13 Jan 2004, Jonathan Phillips wrote:
The big question: Should we then add our GTKMM items back to the roadmap for this release?
Jon
On Tue, 2004-01-13 at 07:41, Bob Jamison wrote:
Nathan Hurst wrote:
In this case it means not holding back a feature because it makes the windows port hard.
That's "build", not "port". ;-)
I agree.
Hey, I was able to add gtkmm to the windows build -before- anyone else!
Yeah. I don't care about "hard", but I DO care about "impossible." I really think dependencies should at least be discussed before we tack them on. Maybe the the person requesting inclusion of the lib should do the investigation.
We also need to see if a given library is really needed in its entirety, or if only a small portion of it is being used.
Bob
This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Not to reply to my own email...but...
Maybe we should add on the roadmap for 0.38 to develop, using GTKMM, a preferences dialog. It could be located at: dialogs/Preferences.h and dialogs/Preferences.cpp
Bulia is doing such nice work on moving things to preferences.xml. Just need a node on our roadmap to allow user's to be able to edit their prefs...
Jon
On Tue, 2004-01-13 at 10:44, Jonathan Phillips wrote:
That's good. That way we can have a solid release without new DEPENDENCIES for anyone using older systems.
Sounds good.
Jon
On Tue, 2004-01-13 at 10:40, Bryce Harrington wrote:
No, but we should add a task to re-examine the situation for the 0.38 release.
Bryce
On Tue, 13 Jan 2004, Jonathan Phillips wrote:
The big question: Should we then add our GTKMM items back to the roadmap for this release?
Jon
On Tue, 2004-01-13 at 07:41, Bob Jamison wrote:
Nathan Hurst wrote:
In this case it means not holding back a feature because it makes the windows port hard.
That's "build", not "port". ;-)
I agree.
Hey, I was able to add gtkmm to the windows build -before- anyone else!
Yeah. I don't care about "hard", but I DO care about "impossible." I really think dependencies should at least be discussed before we tack them on. Maybe the the person requesting inclusion of the lib should do the investigation.
We also need to see if a given library is really needed in its entirety, or if only a small portion of it is being used.
Bob
This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
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
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.
Bryce? You've been quiet so far.
njh
Another comment on the subject of userbase size, to back up Nathan's point.
In the MUD development community there was some observations that contrary to the MMORPG philosophy of "bigger is better", in reality it seemed that the best MUD communities were of around 200-300 people. The thinking is that less than that the number of opportunities to build relationships were smaller, whereas above that, there were too many people so most folks you randomly ran into were not people you knew so it wasn't worth the effort to build the new relationships with them.
I suspect similar reasons are behind why overly successful open source projects change or even die due to userbase overload. We want a good userbase - large enough to make things interesting but not so huge that we have to spend an undesireable amount of our time doing tech support.
The metric I'm watching for this is the size of the inkscape-devel mailing list; when it hits 200-300 I will assume we're at the sweet spot. Based on the volume of list traffic I think we're already pretty close. :-)
Bryce
Great article on that magic 200-300 users. Past that, you lose community: http://shirky.com/writings/community_scale.html
jon
On Tue, 2004-01-13 at 13:25, Bryce Harrington wrote:
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.
Bryce? You've been quiet so far.
njh
Another comment on the subject of userbase size, to back up Nathan's point.
In the MUD development community there was some observations that contrary to the MMORPG philosophy of "bigger is better", in reality it seemed that the best MUD communities were of around 200-300 people. The thinking is that less than that the number of opportunities to build relationships were smaller, whereas above that, there were too many people so most folks you randomly ran into were not people you knew so it wasn't worth the effort to build the new relationships with them.
I suspect similar reasons are behind why overly successful open source projects change or even die due to userbase overload. We want a good userbase - large enough to make things interesting but not so huge that we have to spend an undesireable amount of our time doing tech support.
The metric I'm watching for this is the size of the inkscape-devel mailing list; when it hits 200-300 I will assume we're at the sweet spot. Based on the volume of list traffic I think we're already pretty close. :-)
Bryce
This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
participants (5)
-
Bob Jamison -
Bryce Harrington -
bulia byak -
Jonathan Phillips -
Nathan Hurst