[sword-devel] summary

DM Smith dmsmith555 at yahoo.com
Fri Nov 28 16:55:14 MST 2008


Matthew,
I'll ramble on for a bit.... so maybe this is a response to the entire  
thread and not you!

I'd like to say that if I am a leader here, it is only to the extent  
that people think so. I have control over JSword and little else. I  
have been given permission to maintain the wiki, commit changes to  
utilities and to add/replace modules.

I got those privileges by making so many submissions that it was  
convenient to others for me to have privileges. By volunteering for  
specific opportunities, I got other privs.

Troy, Chris and I see eye-to-eye on some things, but not others.  
However, I find that this is the only open source Bible software  
project and I am willing to bend over to support that effort. I used  
to be (and sometimes, unconsciously, still am) very abrasive and my  
sister, in her own loving way, encouraged me that "it is easier to  
catch flies with honey than vinegar."

Most of my motivation has been to ensure that JSword/BibleDesktop  
works well. That's why I volunteered to cleanup problems that were in  
the KJV 2003. It looked bad in BibleDesktop and because it was the  
most frequently downloaded module, it made BD look bad. When I got the  
opportunity to do ESV, I jumped at it for the same reason.

I have advocated a repository for the sources that we use to create  
modules along with all the scripts used to do so. My reasoning comes  
from having majored in Biology, where all published experiments are  
judged on their repeatability by the scientific community. Additional  
motivation comes from the loss of primary sources, e.g. Bible  
Foundation. Also, I think that each of us needs to work at making  
ourselves indispensable.  This is, IMHO, the root of discipleship.

When we are a primary/authoritative source for a text, CrossWire will  
maintain it under SVN. This is the case with the KJV. When we are not  
the primary/authoritative source for a module, it is the policy of  
Crosswire to point people to where we obtained primary/authoritative  
source. This is recorded in the conf of the module. (My finding is  
that this is not very accurate or maintained well.) It is also the  
policy of CrossWire to discourage the reverse engineering of modules  
into other formats, because we are not the authoritative, primary  
source of the text. Yes, our work is open source, and there are tools  
to extract the module content and even if there weren't a junior  
programmer could figure out how to dump the text. (mod2imp is a very  
simple program!)

With regard to fixing modules, I think there are two kinds of errors:
1) Upstream errors - the text we obtained had errors. In this case, we  
want to provide fixes to that source.
2) Module making errors - the text was fine, but we created a module  
with problems. These we can fix by dumping with mod2imp, making the  
change and re-creating the module.
Without the source, none of us knows which it is and it is up to the  
original creator of the module or someone who can re-obtain the  
original to see where the problem lies. I guess this is another reason  
for us to host the input source.

As to modules hosted on the CrossWire server, I feel that there is a  
strong need for a gatekeeper or two (not much more). The primary  
considerations, in my opinion are:
1) legality - is the work public domain or have we obtained permission  
for the module
2) from a primary/authoritative source
3) broad application support - does it work in the majority of front- 
ends and all the core ones (i.e. BibleCS, JSword, GnomeSword,  
BibleTime and MacSword) that are compiled against the latest SVN. I'm  
very willing for a module to be released to "production" if it doesn't  
work in JSword and even one other front-end [even BibleCS]).
4) Highest quality of rendering in the core front-ends. WRT JSword,  
this means the highest quality of markup. (I'll leave that  
sufficiently vague on purpose.)

WRT to JSword, our process for making changes is fairly straightforward:
1) Our work is driven by "bugs" entered in JIRA. Our first response is  
to fix bugs, then to make all module types supported and finally to  
add new features.
2) I may make changes that are not discussed on jsword-devel, but I  
try to ensure that they are backed by a JIRA entry.
3) All other changes are discussed first on jsword-devel, a JIRA entry  
is created and then patches are submitted. I review the code changes  
and probably will make further changes to keep it in line with the  
undocumented coding style of JSword. Likewise, Peter is our gatekeeper  
for translations.
For the most part, I'll accept any changes that are offered.

I guess what I'm trying to say, as far as I know, I am transparent in  
all that I do here.

In Christ's Service,
	DM


On Nov 28, 2008, at 3:16 PM, Matthew Talbert wrote:

> Troy, Chris, DM and anyone else who is a leader here:
>
>> 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:
>
> 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.
>
> 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.
>
> Open source projects that do not respond to feedback from their
> community either fork, die, or never achieve the success they could
> have had.
>
> Matthew
>
> _______________________________________________
> sword-devel mailing list: sword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page





More information about the sword-devel mailing list