This may be a bit late, but if I may still interject some thoughts...
Here are my 2 cents.
* 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 application
My 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 hella
good stuff in the replies and I am actively resisting diving into
that point
by 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
business
model question in coming weeks.
Objections, comments, praise, endorsements, rotten tomatoes,
lovely roses, ordinary daisies?
Regards,
-t
_______________________________________________
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/
_______________________________________________
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/
