[OSGeo-Discuss] scale of FOSS projects

Thu May 8 06:03:03 EDT 2008

Howard Butler wrote:
> On May 6, 2008, at 3:10 PM, jo at frot.org wrote:
>> In the past i've heard it suggested that really successful open 
>> source projects now need serious organisational backing. They can't
>>  be built by a network of partly-funded enthusiast contributors 
>> alone.
> 
> I think really successful open source projects are successful because
>  of serious organization, not necessarily a fire hose of funding.

Hobu,

I'm also sure that good organization is one of the most important
thing, and the hardest to get up and keep rolling in long run.
It also helps projects to move smoothly and gives an impression the
motion is resistant to obstructions. Indirectly, it's somehow a
guarantee that a project will stay alive for long(er) time.

> I think OSGeo wants projects that are thriving communities for a 
> number of reasons, but I'll leave it up to others to decide if we 
> actually meet that bar with all of our projects.

I'd add interesting project that are going to build thriving
communities with the help of OSGeo. IOW, OSGeo could help some
projects valuable to the FOSS4G world to get open and alive in terms
of live participation in them.

> Serious organization requires infrastructure -- something that's easy
>  enough to get these days (SourceForge, Google dev, even OSGeo if you
>  can jump through the hoops) -- but more importantly, it requires 
> *use* of that infrastructure.

Yes it does. Karl Fogel describes it very well in his book
(http://producingoss.com). I strongly recommend it to project leaders
and developers who maintain just-opened and want to get dirty with
principles of the FOSS world.

> One thing that I have found out recently when developing on a small 
> open source project (http://liblas.org) is that Brook's notion about 
> geometric communication load applies.  With a one or two person 
> project, does it make sense to file every notable change into a bug 
> tracking system, ensure that changesets only deal with one specific 
> issue, and avoid communicating about design and code organization in 
> forums that do not log things for posterity?

Yes, it *does* :-)

Let's use libLAS as an example of a newborn project. The community is
very small, but its developers are going to grow it. IMHO, even a small
team should exploit all available tools to increase chances of community
development, from the beginning. The tools I have in mind are included
in project infrastructure: lists, svn, bug tracker, website, blogs, etc.
If we move project discussions to the lists, the chances that someone
will encounter it get higher.
If we make a website, send some posts to our blogs...chances are higher.
Now, to answer your original question about submitting tickets I will
compile my answer using citations from Fogel's book:
(http://producingoss.com/en/getting-started.html#vc-and-bug-tracker-access)

"The importance of a bug tracking system lies not only in its usefulness
to developers, but in what it signifies for project observers. For many
people, an accessible bug database is one of the strongest signs that a
project should be taken seriously."

Why?

"Furthermore, the higher the number of bugs in the database, the better
the project looks. This might seem counterintuitive, but remember that
the number of bugs recorded really depends on three things: the absolute
number of bugs present in the software, the number of users using the
software, and the convenience with which those users can register new
bugs. Of these three factors, the latter two are more significant than
the first."

and the last that actually convinced me to this idea:

"A project with a large and well-maintained bug database therefore
makes a better impression than a project with no bug database, or a
nearly empty database."

> The overhead to do that stuff is fixed, and quite expensive 
> especially considering that you only have one or two folks writing 
> the software hoping to get it to a functional point.

Yes, it does but please notice that the libLAS is a *very* young
project, and we still don't know what is it potential, how many people
it may interest, etc. We will know after 6 months or more, but not after
2 or 3. So, IMO one of the important role we have is to make a lot of
noise to reach potential users and developers.

FOSS projects usually have no resources to advertise themselves on TV,
but thay can generate a lot of traffic on the Net.

Getting back to overhead, when I started to work as a FOSS freelancer ~2
years ago, I didn't know that overhead, though I've been FOSS
contributor for >4 years before that. After 2-3 months, I encountered
that I'm writing *less* code per day than when I was working 8 hours a
day for a non-FOSS company and was spending ~2 hours a day coding for
FOSS after hours. I couldn't believe that fact, but it was (is) true.
Actually, it was a little disappointing because writing code is the only
thing I'm interested in my work life :-)
I analysed what was/are the reasons and I found that 1-2 hours of my day
I spend on reading/writing e-mails. Another 1-2 (or more)
hour I spend talking on IRC. These activities eat 1/2 of my day!
It has some implications in the GDAL maintenance contract I have
pleasure to run - Frank agreed I count hours spent on GDAL e-mails and
(partly) IRC talks as providing GDAL support.

I still can't agree with the fact of overhead, and I'm still thinking
how to organize my day better (have to try Allen's GTD), though I see it
in black colours :)

However, there is something that eases my mind: Fogel's book confirms
clearly that there *is* a lot of overhead caused by FOSS projects
maintenance and development. And it is not uncommon.

>> If a project has a given amount of momentum, marketing resources 
>> applied to it, a contributing user community; is there any sense in
>>  "competing" by building something new with a lot of conceptual 
>> overlap? If there isn't, don't de facto monopolies start to develop
>>  inside FOSS as much as they do in proprietary software systems?
> 
> There sure is a reason to compete -- to build (or aspire to build) a
>  better product.  MapServer, for example, has Mapnik.  I think
> Artem's quest to show us how wrong we were has had a positive impact
> on both projects (speaking as a MapServer dev).  Each software does
> different things better, and both projects have driven innovation in
> the other.

I agree with it. I only think that there is a tolerance barrier.
If number of projects doing the same thing (but implemented in different
language or coding style) will increase too much, their communities will
get small or very small, so less powerful.

> I would say that Mapnik still doesn't have all of the inertia that 
> MapServer enjoys, and I think it suffers from some of the 
> organizational challenges I described above (MapServer too), but from
>  my perspective it has been steadily gaining steam and meets any 
> definition of open source success.  It hasn't needed OSGeo to have an
>  impact.

Yes, Mapnik is definitely a success and check how many entries it has
in the AUTHORS file, namely *two*

Greetings
-- 
Mateusz Loskot
http://mateusz.loskot.net