|
| From: | Talli Somekh |
| Subject: | Re: [Gnu-arch-users] arch 2.0 survey followup |
| Date: | Sun, 30 Apr 2006 14:55:30 -0400 |
* Asking which market is ideal may be inappropriate given the skills in the community. There are no MBAs around here and while some may think that is a net positive there is a skill set that shouldn't be ignored.
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.
* 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:
--SoftCo is a software company that develops a J2EE middleware application. The development team consists of 5 hackers, 2 QA people, 1 sysadmin and 1 manager. Each hacker has a Xeon workstation with 1GB of RAM and 500GBs of disk running Red Hat Linux. QA tests on Solaris, Linux and BSD. The sysadmin manages all the boxes and servers.
The hackers each work on their desktop and commit to a central repository from which they periodically merge from. They also regularly merge from one another according to the ad hoc teams that form to develop particular modules or features.
QA tracks daily snapshots and submits them to an automated testing framework. The framework is a series of scripts that report successes and failures according to heuristics defined by the team. QA is responsible for interpreting the reports and submitting bugs to a bug tracker the entire team has access to. "Scriptability" of the code repository is critical so that the system can easily be integrated with the various third party tools they use.
The sysadmin is responsible for the maintenance, health and administration of all the systems in the network including servers and workstations. She is also responsible for creating regular backups of the RCS and the working order of the testing framework. While most of her energy is spent performing repetitive tasks, her chief concern is the security and reliability of the system because in the few times there have been breaches in one of these areas she has spent many sleepless days working full time recovering the systems. She would like a system that fits seamlessly into the stack of software components she feels most comfortable with, namely her web, email and file servers.
The manager is a former hacker that no longer develops code but is interested in regular reports regarding the progress of the team. She is interested in also in having complete logs in case of security breaches or code conflicts so that audits can take place. Automatic reports that can be generated from the RCS that describe progress, commit frequency and total size among other characteristics of the repository are also very helpful.
---The workflow for this group can continue from here. I might recommend setting up a wiki where such a scenario can be collaboratively developed. Other scenarios that should be developed include:
- Small community of free software developers - Content developers who need a RCS for developing a wiki applicationMy opinion and experience suggests that these exercises, informed by experience, can immeasurably shape the design process.
* Windows is critical. I have inside information that one of the biggest software companies in the world evaluated GNU Arch but rejected it in favor of Perforce because windows was not supported. This was before the Great Schism when everything went Python.
* A GUI is critical. A thought that Tom and I discussed previously was to build a GUI using a web framework like Ruby on Rails that has very good ajax functionality so that a rich GUI can be built that is cross platform and can be run either in a client server enviro or as a desktop app. Designing the system with thoughts about a GUI now using a light framework atop of the system would be a big win, particularly when one of the potential users is a manager (see scenario above).
talli On Apr 30, 2006, at 5:38 AM, Thomas Lord wrote:
So, I'm sorry to be late and terse replying to the feedback to my "fill in the blanks" questions about 2.0. I asked about target markets and their needs and, somewhat ambiguously, about business model. I spent a few hours reading and cutting and pasting and generally contemplating the replies. There was a hecka good amount of hellagood stuff in the replies and I am actively resisting diving into that pointby point. I'm resisting doing that to keep moving forward. So, here is my proposal for a statement of rough consensus on just the essentials: * Target Markets ~ small projects, including isolated individuals ~ huge projects, like GNU/Linux distros ~ GNU project developers in general ~ projects desiring sophisticated patch-flow mgt. ~ not-specifically-hackers, especially web-content teams, system admins (maintaining /etc), and personal computer users (maintaining their (possibly distributed) home directory. * Needs Simplicity, speed, portability to Windows (but not at any serious cost to GNU systems), and ideally a nice GUI * Business Model We'll talk about that later. This is not a bad starting point, if there is some general agreement to it, imo.I'd like to next turn to some design questions (call that strategy) and then some tactics questions. I'd also like to gently raise the businessmodel question in coming weeks. Objections, comments, praise, endorsements, rotten tomatoes, lovely roses, ordinary daisies? Regards, -t _______________________________________________ Gnu-arch-users mailing list address@hidden http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/
| [Prev in Thread] | Current Thread | [Next in Thread] |