[sword-devel] summary

[Chris Little]

Matthew Talbert wrote:
> From my perspective, the community that has built up around the sword
> project is asking and pleading for a few changes. It is very clear
> looking through the archives from the past year that there is
> considerable discontent, and desire for a few simple changes. Two of
> these changes that appear to have complete consensus from everyone
> except perhaps the three this is addressed to are these:

Let us not confuse the vociferousness of a small group for massive 
public outcry. Five voices of the hundreds on this list do not a 
consensus make.

> 1. Find some way to increase transparency in the module submission
> process. There have been several suggestions made, many of which could
> be implemented easily. It appears that the biggest complaint is that
> Chris has entire control of the process without any oversight or
> accountability of the modules at crosswire email address. In open source
> as well as in government, openness and accountability are always
> helpful in decreasing discontent. Although there have been many
> allegations made, I'm not accusing Chris of anything here, just saying
> that it would decrease discontent if there was more openness.

It sounds as if you should dedicate considerable time to producing an 
OSIS document submission, validation, and vetting mechanism, as DM 
mentioned has been on the TODO list for some time.

> 2. The sword project should maintain sources via svn of at the very
> least the public domain resources. There is very clear community
> consensus on this point as well.

It sounds as if you should dedicate some time to producing, at the very 
least, a proof of concept, e.g. the plan to update & maintain Easton's 
dictionary in SVN.

You're committing a bit of feature-creep here in your expression of what 
"clear community consensus" is, as previous statements have suggested 
maintaining libraries, but not specifically in SVN. I don't think the 
SVN idea is a terribly good one, especially not on crosswire.org.

The concept also requires buy-in from module developers in order to have 
their permission to publicly host documents, essentially giving 
permission to anyone else to modify them and to any other project to use 
them. Speaking for myself, aside from some educational purposes, which 
can be achieved by posting a few sample documents, I can't see much 
reason to buy in.

> Open source projects that do not respond to feedback from their
> community either fork, die, or never achieve the success they could
> have had.

Forking isn't really a concern for me. I haven't noticed so many commits 
in SVN to suggest that anyone might be willing to take the codebase and 
drive development at another site. I'm not sure how one would even go 
about forking such a project as this, considering all of the logistical 
and rights issues that would have to be re-done. And then there's simply 
the issue that the (actual) vast majority of people in this community 
have expressed no discontent, and those who actually do most of the work 
  aren't considering going elsewhere.

Dying isn't really an issue, ignoring the improbable case of all of the 
big contributors to the project literally dying in short order.

And, frankly, no one and no project will ever achieve the success he or 
it might have had. That just follows from our inability to tell the future.

We are listening to your feedback and your opinions. That does not mean 
that we will do everything you (or even a group of you) suggest. Your 
voice at CrossWire will not grow by using more words or pleading more 
plaintively. Talk is cheap.

If you want something done, do it yourself. If you are unhappy with the 
current workflows, come up with an alternative that fits within our 
requirements and demonstrate a working proof-of-concept. If this is a 
priority for you, you need to be the prime mover.

--Chris