But if there is interest in doing a market analysis, I recommend
first doing a complete competitive profile to understand who the
competitors are and what are their strengths and weaknesses. Then
perform a review of what users seek from a RCS. From there, a gap
analysis can be created that defines a set of features that can
provide a target for a differentiated application.
I only partly agree with that recommendation. The main thing that
I disagree with is the use of the words "first", "then", and "from
there". To a lesser extent, I disagree with "from a RCS".
fair enough. the order doesn't matter as much as the exercise
although understanding the competition is helpful in design.
Now, we have a design problem and don't have an a priori
understanding of the constraints that design that problem.
which is clearly not the situation with GNU arch but is also not a
bad perspective from which to begin from. at least in so far as open
minds can help inform situations when subconscious NIH or plain
obstinance can undermine innovation.
I strongly agree that the kind of analysis you suggest is important
and valuable, though. I'm beginning to think that, in very
literal terms, the source tree for Arch 2.0 ought to have a
directory set aside for this kind of analysis. Maintaining and
improving it should be part of the project. The initial contents
can be quite crude but over time, it should be tuned up. It's
part of the project's documentation.
that's good. leaving all political and social opinions aside, Martin
Pool did do a rather fine job preparing a set of documents about the
competitive landscape prior to beginning work on bzr. i recall a wide
survey of the free, open source and proprietary applications
available and their relative strengths and weaknesses.
unfortunately, he arrived at a rather naive conclusion that a DRCS
only needs "around 12 commands" to solve most problems. second hand
reviews i've of the application have been quite good but have begun
to complain of feature creep and/or increasing complexity. such are
the dangers, i imagine, that you are referring to if one lets market
analysis define product development.
* The current set of "markets" are so disparate as to make
"targeting" them almost satire.
An alternative exercise that IMO may be more effective for the
community's planning for 2.0 is to develop a set of scenarios.
Each scenario describes the relationship between various classes
of users and their application of a feature set. For instance:
We have the humble beginnings of that, especially in the comments
from Matteo and Aldrik. Check it out -- they wrote some really
good thoughts!
Yes, I noted Matteo's in particular.
I think the example you go on to give (which I encourage people to
go back and read) does a good job of pointing out the level of
specificity and the focus of attention that is ultimately
desirable. I'm not sure that, at this junction, I want to hold
up things to insist on perfecting our scenario analysis. It's
something to iterate over, just like the code. Crawl. Walk. Run.
iterating is a good idea, as long as the iterations are independent
from the code iterations you're hacking! it would be a disaster if
the scenario was dictated by the design choices of the application.
to some degree that's good (letting the application define best
practices for you) but the creation of the use case needs to inform
the architecture as a client would inform the consultant.
* Windows is critical.
I think that's really clear.
To an extent, it can only help the quality of the code to be
portable in that way. It takes nothing away from the GNU mission,
only helps, to make sure Windows is well supported.
Glad to hear this.
All that said, I don't think there is any better choice than to (a)
build a GUI in parallel with the
core functionality; and (b) build that first GUI using RoR.
whether it's ror or another framework or not a framework at all
matters little. as long as the app is AJAX based it's a very nice
feature.
RoR is simply a nice choice because it's the most popular framework
out there. buzz word compliance is a strong selling point.
Building a GUI in parallel avoids a waterfall approach to making
sure a GUI is possible. It also ensures that (since we are
talking about supporting users who are sure to prefer a GUI) the
core functionality design evolves with real feedback about how it
looks from a GUI perspective.
yes.
Building a first GUI with RoR is appropriate because it's so
freakin' easy compared to alternatives; because revolutionizing
web-gui frameworks is not (yet? :-) central to the Arch project;
because lots of people will know from day one how to hack it; and
because I think we are safe in assuming that RoR will just keep
getting better and better in the short and medium term. I'm sure
there are other reasons, too.
yes.
talli
_______________________________________________
Gnu-arch-users mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/gnu-arch-users
GNU arch home page:
http://savannah.gnu.org/projects/gnu-arch/
