Hi Matt,
I think that we basically agree.
We'll be contributing as much as we can to the community, while also
finding ways to keep the overall enterprise funded. For better or for
worse, our model has been to invest a lot in development -- with no client
or other funder paying for anything whatsoever -- then make it up in user
fees. Since we're trying to pay development costs retroactively, it's a bit
more difficult than if we had sponsors to fund initial development. I'm
sorry, though, if that puts you off, or if we weren't clear about that.
I've tried to be very up-front, but I fully understand the confusion -- and
the reaction.
Best,
Chris
···
On Thu, May 16, 2013 at 2:23 PM, Matt Berg wrote:Chris,
It's a bit of a misnomer to presume that if you are at a university you
are just handed money to make stuff. In reality, almost everything we've
built has been a result of having to build something for a client or
project and we've tried to share as much of it as possible back.That's here nor there. I guess I'm maybe a bit thrown off because I came
across this discussion on the ODK developers mailing list talking about
XLSForms, and dynamic-search-and-select widgets something that has been a
feature request for a long. Since I thought it had implications re:
potentially modifying the XLSForm spec and your interest to "kick back
something into the main stream" i got pretty excited and tried to spend the
time to understand the issue.I think you can be a social venture while striking the balance but that's
your decision to take. For me striking a good balance would be keeping all
the hard-work you've put in on the server side to make these pull downs
easy to configure client but sharing back some of the "contributable" mods
back to collect. I don't think any begrudges the approach you've taken with
SurveyCTO especially if you are to provide a quality service that people
like. A bit of quid-pro-pro though will really go a long way though.
That's been part of the ethos I feel has had being part of the ODK
community special even though a lot of us are in a bit of a natural
co-petition. There are so many challenges we face (with so little
funding). That's why the idea of having to reengineer something that
should probably be part of the xlsform spec, while you maintain an update a
fork of collect is a bit frustrating. Ultimately, you'll need to figure
out the best approach for "maximizing" your return keeping in mind that
it's important to help nurture the garden you are in.Thanks,
Matt
On Thu, May 16, 2013 at 2:10 PM, Christopher Robert < chrislrobert@gmail.com> wrote:
Hi Matt,
Sure, I completely understand where you're coming from.
Any organization contributing to an effort like this has its own funding
and sustainability considerations. If we were a grant-funded nonprofit, or
based at a university, our considerations would be very different. The work
I myself do through my research or with my university, for example, flows
into the public domain much more readily. As a business, however, SurveyCTO
is simply organized differently. That doesn't mean that we're not
interested in maximizing social value, nor that we're not interested in
contributing to the open-source community. It just means that securing
revenue to offset expenses is an important consideration, just as the
availability and terms of relevant grants would be considerations for any
nonprofit or university-based organization.In recent years, there has been a lot of talk -- and a lot of hype,
frankly -- around the concept of "social enterprises." I have myself been
skeptical at times. However, I do believe that it is possible to avoid a
polarized world inhabited by greedy, self-serving corporations on the one
side and altruistic, well-meaning public and nonprofit organizations on the
other. SurveyCTO resides in an organization set up to operate somewhere in
the middle, where products and services that contribute lots of social
value are produced for customers who pay for those products and services.
In the process, we hope to generate lots of "surplus value," well beyond
the cash that changes hands. Obviously, the open-source community is one of
many conduits for this surplus value.In the policy world, we often say that "where you stand depends on where
you sit" (Miles, 1978). Along those same lines, I suspect that your views
and mine are not very different, though in practice there may be some
differences based on where we sit (for example, where our salaries come
from). Luckily, I think that diversity within the open-source community is
probably a healthy thing.Best,
Chris
On Thu, May 16, 2013 at 11:39 AM, Matt Berg mlberg@gmail.com wrote:
Chris,
I understand the challenge but it we had taken that approach selecting a
different licensing scheme on tools we've spend over a year investing in
(pyxform) and uw building odk building aggregate, briefcase and collect
then your service wouldn't be possible. Same goes for tools like enketo too.We infact have referred paying customers to survey cto because we
thought it offered a bettered fit for their needs then we were currently.
It's hard I realize but it's the only way we collectively can really
afford to move forward in a meaningful way. I still think its possible to
contribute some features back especially on the client side that doesn't
jeapordize your ability to offer a great service people will pay for.If not others in the community will jist just need to reengineer things.
I'm not saying it will work for any org to make all of their work
opensource but I think they should all take seriously the importance of
contributing back to the community given the resources and effort so much
have contributed in. I think this especially applies to making
obvious/functional improvements to a tool that you didn't make in the first
place.I understand and respect what you are trying to do. Open source is
tricky. I hope you can see thoigh where I'm coming from.Thanks,
Matt
On Thursday, May 16, 2013, Christopher Robert wrote:
Hi Matt,
While in principle I'm open to sharing even major new features back
with the community, in practice I'm a bit limited by our funding model.
Essentially, user fees are the only way that we can cover our development
costs, so we invest a whole lot in development, then we collect a stream of
user fees (minus hosting and support costs, which account for a substantial
portion of our fees). To the extent that new features unique to SurveyCTO
drive customers and therefore revenue, they become an important part of the
overall model.Obviously, our model also fundamentally relies on a thriving,
productive ODK community, and our motivation is social in nature -- we care
most about the social value produced by our work -- so what to share, when,
and how becomes somewhat complicated. We're basically trying to figure it
out as we go along. In the case of major new features like pre-loading,
audio auditing, etc., we have to think hard about how to make sure that we
recoup our development costs so that our overall effort is sustainable.
After all, I truly believe that we'll contribute most to the community if
we survive and prosper.On linking to a URL, yes, already we can see that having one form's
export feed more seamlessly into another form's pre-load would be extremely
helpful. That might be precisely the kind of flow that ODK 2.0 will handle
extremely well, but you're right that it may be a while before 2.0 is out
and widely adopted.Also, a key issue is data-security: for SurveyCTO, we've generally
taken the approach that Internet servers should never be able to read
personally-identifiable data. To that end, we expect that many of our
clients will hand-copy .csv files onto their encrypted devices, so that
they never pass through SurveyCTO servers. Alternatively, we're thinking
about adding an ability for clients to encrypt their .csv files if they
want to be able to easily upload/download them with their forms. That sort
of thing would further complicate the data flow, but it seems necessary to
protect sensitive data.Best,
Chris
On Thu, May 16, 2013 at 10:41 AM, Matt Berg mlberg@gmail.com wrote:
Chris,
Completely understand about blazing ahead. At the same time, I think
these are great contributions and it really behooves us as community to try
and ensure our xlsforms can be compatible across tools (it's up to backend
to implement of course).I realize ODK 2.0 will address a lot of these issues but I think there
is still the footprint of ODK 1.0 is so large and the tool is so reliable
(it will take a while I think before people will switch for major project)
that I think adding in support for basic dynamic queries and injections
like this will still introduce a tremendous amount of value. I'd also be
really curious to see how the filter works. That sounds like a good way of
addressing this issue.I understand the simplicity of going with the media upload and think
that's a good short term fix. The reason I'm so keen on the url approach
though is you could link it to the export of a data set. Ie) you could
have a very simple village registration form which would allow you to
dynamically create a list (syncing required obviously).Do you have plans / can you contribute the changes your making to
collect back to the core? Even if these features are in an experimental
branch in the beginning? I think it would make a huge contribution to the
community.Thanks,
Matt
On Thu, May 16, 2013 at 11:22 AM, Christopher Robert < chrislrobert@gmail.com> wrote:
Hi Matt,
Thanks for your reply.
The search() query examples in that example form were just meant to
experiment with different syntax options, so they actually don't make much
sense as actual queries; the case where I'm querying district using a
village name was somewhat nonsensical. The idea is that you'd be able to
search any .csv column for any string value, and we're implementing four
types of search queries: exact, contains, starts-with, and ends-with. The
syntax is still in flux as we work on the implementation. (We're now adding
a "filter" option, for example, so that you can search within a subset of
the .csv data.)Our pulldata() support has already been released, and you're right that
it only allows you to pull one field at a time. That's a definite drawback
in cases where you're pulling lots of data from the .csv, and the kind of
dict-based approach you suggest could make a lot of sense.You're also right that, as things stand, you have to upload .csv files
with every form, so a URL reference would be better for cases where the
same .csv is shared across multiple forms. However, then there would need
to be a separate system of maintaining/updating .csv files. With the .csv
files as part of the form, they essentially piggy-back onto the existing
form versioning system, and it's relatively easy to keep track of the fact
that .csv files basically come with the form (and you can download a new
form definition to update the .csv files).Obviously, ODK 2.0 has a much richer method of flexibly dealing with
different data flows, and our intent was not so much to create an
alternative approach. Rather, we simply wanted to provide for some basic
ability to deal with pre-loaded data in the short-run since it seemed like
such a great and urgent need for many users. Our approach has been to try
and fit within the existing ODK 1.0 architecture to the greatest extent
possible, and to just work the basic pre-loading support in with the most
graceful methods we can manage.Generally, we've been trying to do things with the minimum necessary
changes to ODK code, conditional on providing a decent interface for users.
That's why, for example, we have built a series of "expression builders"
within the SurveyCTO web interface, to make it as easy as possible for
users while sticking, for the most part, with the existing XLSForm
implementation. So, for instance, "Pull field from pre-loaded .csv file" is
an option in our "calculation builder," which helps then construct the
proper pulldata() call.These new fe
--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.