Re: arch 2.0 survey followup

>> 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