|
| From: | Talli Somekh |
| Subject: | Re: [Gnu-arch-users] arch 2.0 survey followup |
| Date: | Mon, 1 May 2006 12:58:45 -0400 |
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.We have the humble beginnings of that, especially in the comments from Matteo and Aldrik. Check it out -- they wrote some really good thoughts!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:
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 thecore 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
| [Prev in Thread] | Current Thread | [Next in Thread] |