Re: [OSGeo-Discuss] scale of FOSS projects
[...] > There is this cultural pressure on "standards" to be marketing tools. > Because of the government and military context for GIS, this pressure > is particularly intense for us. It starts to loop back on itself somewhat > like this, http://frot.org/on_standards/statements.html Jo, Thanks for sharing the standards statements. Coming back to spatial - it is a natural tendency for spatial data to come full circle because allegedly (to this day I could not really prove this with my own bodily sense organs) we are living on a ball. This creates a natural need to overlap, overlay, unify, reuse and intersect its virtual representations. Something much less natural to a written text (for a start we could try to intersect an ODT with the latest ROA definition with a SOA definition rendered in a DOCX and overlay them with a WSDL schema to extract the OGC reference model) Hehe. > This does have a countereffect on innovation in software and it also > probably does prevent "bona fide" standards developing in a natural way. As > well as creating this terrific and largely justified backlash against some > of the in-a-vacuum work done by OGC, ISO. (GeoDRM anyone) Yes - this is of utmost pain to me. Geospatial Restriction Management puts the fences that we left behind in the real world when we moved to virtual right back. And DRM is intensely tied to data that is only accessible with one software - the one that exclusively implements the restricted access. This software needs legal protection because all technical protection is always utterly worthless (thank Dog or whoever else signs responsible). Hence the OGC *idea* must cringe and writhe in pain when only addressing RM. The consortium seems to be taking it all right, but that is only the worldly instance of the idea itself. > However the process of working things out by rough consensus and running > code takes longer, business process says, "first to market -> "natural > monopoly| de facto standard". I would like to add here that there might also be a natural need for de jure standards - which brings us back to governments adopting standards. Unfortunately we (humanity at large) are still so violently egoistic, self centered, illiterate and uncivilized that there seems to be a need for legal frameworks (consented - this is becoming a little broad...). What it boils down to is that this creates a need for a stable, legal framework - and I'd rather have it based on open formats instead of depending on a certain software (regardless of whether it can be hacked or not). The solution is to clearly separate data from software and model the data in a fashion that makes it accessible. Did I day this before? Maybe I did. Best regards, ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] scale of FOSS projects
wrapping up... On Fri, May 9, 2008 00:32, Miles Fidelman wrote: > P Kishor wrote: > >> On 5/8/08, Schuyler Erle <[EMAIL PROTECTED]> wrote: >> >>> One important point that Fogel makes that I think is worth noting >>> here is that the number-one sine-qua-non of *any* potentially >>> successful software project is *shipping working code*. >>> >>> Until a developer does that, the discussion of whether or not his/her >>> project needs or deserves institutional/organizational support to >>> succeed further is moot. >>> >> >> Steve Coast (OSM) echoed the same sentiment very elegantly -- "Real >> artists ship. For everyone else, there is wanking." >> >> After a short hesitation, I have really come to appreciate it. Yup, >> unless there is working code, everything else -- sponsorships, >> organization, standards, committees, mailing lists -- is pointless. And now SteveC burns a few million on a cloudmade commercial entity - because he comes from this same earth as we all and seems to need to pay the rent as well. It is good that he is so vocal because it will allow us to learn how to build a business around one's Free Baby without running afoul. [...] > pretty hard for one person to accomplish all that much, in a short amount > of time, in odd hours outside their day job. [...] I am sick and tired of the myth that any and all Free and Open Source Software needs to be done by volunteers in the wee hours of the night for no pay. This is simply a big pile of bullshit, get over it. If you really want to hack on Free and Open Source Software big time then get yourself a job that pays you to do exactly that. Ahrg! The other one that makes me rage is the myth that because somebody makes money off something she must turn foul. Anybody can do ethically sound business with well paid happy employees and satisfied customers any time. If you fail you did not try hard enough. Stop whining and get better. As a side note: I stopped coding years ago because someone had to attend to the business side of things. Being the poorest hacker sentence was passed on me. Hard luck. Now we can pay 25 people doing nothing but FOSSGIS. -- Mr. Anti Christl Unloved Business Jerk ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] scale of FOSS projects
IMO: Well said Jo. > > I know, this argument has gone round and round in the past, and many > are impatient with philosophising. I hope that philosophising can > sometimes provide energysaving insight, or i wouldnt engage in it. But > repeating "without code, you are nothing" grates on the nerves after a while. > I'd also echo the sentiment with regards to OGC Standards bashing. One of the key reasons that we as a reasonably large organisation are looking seriously at adopting and contributing further the Open Source spatial world is because of its strong support for OGC standards. +1 to Frank's comments. Bruce Bannerman Notice: This email and any attachments may contain information that is personal, confidential, legally privileged and/or copyright.No part of it should be reproduced, adapted or communicated without the prior written consent of the copyright owner. It is the responsibility of the recipient to check for and remove viruses. If you have received this email in error, please notify the sender by return email, delete it from your system and destroy any copies. You are not authorised to use, communicate or rely on the information contained in this email. Please consider the environment before printing this email. ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] scale of FOSS projects
Frank Warmerdam wrote: ""Real artists ship. For everyone else, there is wanking." Folks, For the record, while I acknowledge a kernel of truth in this, I find the statement so elitist and dismissive of the varied efforts that it takes to make things work that I cringe every time I hear it. +1 There are a lot of people sitting on our GIS lists with impressive shipping credentials who do a lot of talking as well (SteveC included). -- Cameron Shorter Geospatial Systems Architect Tel: +61 (0)2 8570 5050 Mob: +61 (0)419 142 254 Think Globally, Fix Locally Commercial Support for Geospatial Open Source Solutions http://www.lisasoft.com/LISAsoft/SupportedProducts.html ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] scale of FOSS projects
Frank Warmerdam wrote: ""Real artists ship. For everyone else, there is wanking." For the record, while I acknowledge a kernel of truth in this, I find the statement so elitist and dismissive of the varied efforts that it takes to make things work that I cringe every time I hear it. Discussion, conferences, standards, coordination, etc all play an important role in making a software ecosystem useful. If there is a lesson, it may be that these other things shouldn't become so all consuming that they prevent actually producing useful software. Well said! And let me add: lab directors (academic and commercial), proposal writers, IT managers who recognize the value of open-sourcing internally generated code, research funding agencies (DARPA and NSF program managers!) - i.e., those who find ways to pay people's salaries to write code - are an important part of the ecosystem. -- Miles R. Fidelman, Director of Government Programs Traverse Technologies 145 Tremont Street, 3rd Floor Boston, MA 02111 [EMAIL PROTECTED] 617-395-8254 www.traversetechnologies.com ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
RE: [OSGeo-Discuss] scale of FOSS projects
Jo, You wrote: " I really enjoyed the recent discussion here about non-developers contributions to open source projects and communities. Writing documentation and tutorials and maintaining translations, in particular. That code-jockey primacy attitude is potentially alienating to people wanting to contribute this kind of hard work." It is interesting that you bring this up. Almost all of our documentation and translation work at OpenJUMP is done by non-programmers active in the community. In fact, I even take care of commiting updated translation files to the SVN for one of these users. Without these efforts, we might not ever get anything documented. :] You wrote: " At least Autodesk, for example, saw this and made bona fide effort to "build community", rather than dropping millions of lines of undocumented, hard-to-configure code onto the net, hoping an imaginary "open source community" would sprinkle pixie dust onto it, as Sun did at first - as if the time and goodwill of potential contributors were inexhaustible." Excellent point. It takes more than pixie dust to build a healthy community around an open source software project. Landon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, May 09, 2008 7:27 AM To: [EMAIL PROTECTED]; OSGeo Discussions Subject: Re: [OSGeo-Discuss] scale of FOSS projects On Thu, May 08, 2008 at 05:14:40PM -0500, P Kishor wrote: > On 5/8/08, Schuyler Erle <[EMAIL PROTECTED]> wrote: > > is that the number-one sine-qua-non of *any* potentially successful > > software project is *shipping working code*. > > Until a developer does that, the discussion of whether or not his/her > > project needs or deserves institutional/organizational support That is not what this discussion is about, though. (And the point seems self-evident, given this is a discussion about open source software projects, defined by having working code "in the wild") > Steve Coast (OSM) echoed the same sentiment very elegantly -- "Real > artists ship. For everyone else, there is wanking." > After a short hesitation, I have really come to appreciate it. Yup, > unless there is working code, everything else -- sponsorships, > organization, standards, committees, mailing lists -- is pointless. I really enjoyed the recent discussion here about non-developers contributions to open source projects and communities. Writing documentation and tutorials and maintaining translations, in particular. That code-jockey primacy attitude is potentially alienating to people wanting to contribute this kind of hard work. For many it is easy to write software. There is a lot of code out there, a lot of abandon-ware, projects that are "free" by a legal definition but with none of the supporting infrastructure that helps them to get used and to acquire a client base. At least Autodesk, for example, saw this and made bona fide effort to "build community", rather than dropping millions of lines of undocumented, hard-to-configure code onto the net, hoping an imaginary "open source community" would sprinkle pixie dust onto it, as Sun did at first - as if the time and goodwill of potential contributors were inexhaustible. There is this cultural pressure on "standards" to be marketing tools. Because of the government and military context for GIS, this pressure is particularly intense for us. It starts to loop back on itself somewhat like this, http://frot.org/on_standards/statements.html This does have a countereffect on innovation in software and it also probably does prevent "bona fide" standards developing in a natural way. As well as creating this terrific and largely justified backlash against some of the in-a-vacuum work done by OGC, ISO. (GeoDRM anyone) However the process of working things out by rough consensus and running code takes longer, business process says, "first to market -> "natural monopoly| de facto standard". It is unfortunate, because proper interoperability can be such a force for good - cf MetaCRS, and the future time and hassle that is going to be saved for many people, once the inevitable initial round of talking is done. I know, this argument has gone round and round in the past, and many are impatient with philosophising. I hope that philosophising can sometimes provide energysaving insight, or i wouldnt engage in it. But repeating "without code, you are nothing" grates on the nerves after a while. jo -- ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss Warning: Information provided via electronic media is not guaranteed against defects i
Re: [OSGeo-Discuss] scale of FOSS projects
[EMAIL PROTECTED] wrote: On Thu, May 08, 2008 at 05:14:40PM -0500, P Kishor wrote: On 5/8/08, Schuyler Erle <[EMAIL PROTECTED]> wrote: is that the number-one sine-qua-non of *any* potentially successful software project is *shipping working code*. Until a developer does that, the discussion of whether or not his/her project needs or deserves institutional/organizational support That is not what this discussion is about, though. (And the point seems self-evident, given this is a discussion about open source software projects, defined by having working code "in the wild") I would beg to differ. There's a lot that goes on BEFORE working code is released into the wild. And very often, institutional support is what makes it possible to write code and release it into the wild. In a previous life, I ran a small hosting business, and relied entirely on open source code. With the exception of Linux - admittedly a big exception - everything else I was running had institutional origins, with significant amounts of funding supporting the original developers. Of particular note: Apache: started as the NCSA daemon, funded largely by NSF (if I recall correctly) Sendmail: derived from ARPANET delivermail, developed in the university environment Sympa: open-source mailing list manager developed/supported by consortium of French universities These days, one of the things I do for a living is pursue government funding so that our firm can develop new software. One of our current projects very explicitly commits, contractually, to releasing our results under the GPL. (Historical note: until the late 70s/early 80s, work performed with government funding was generally released into the public domain - and an awful lot of today's technology base dates back to those years. IMHO, open source licenses are a reaction to the change in policy that allows companies to maintain proprietary rights to publicly funded work). Miles -- Miles R. Fidelman, Director of Government Programs Traverse Technologies 145 Tremont Street, 3rd Floor Boston, MA 02111 [EMAIL PROTECTED] 617-395-8254 www.traversetechnologies.com ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
RE: [OSGeo-Discuss] scale of FOSS projects
I wasn't trying to apply this quote to all forms of non-programming support on open source projects. I was applying it to programmers like myself, that have 52 projects in their Eclipse IDE, but only two Ant scripts that actually produce a working JAR file on a regular basis. It seems my bad habit of starting things before I complete existing tasks flourishes in my programming. That is the type of wanking to which I referred. :] Landon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Frank Warmerdam Sent: Friday, May 09, 2008 7:29 AM To: OSGeo Discussions Subject: Re: [OSGeo-Discuss] scale of FOSS projects > ""Real artists ship. For everyone else, there is wanking." Folks, For the record, while I acknowledge a kernel of truth in this, I find the statement so elitist and dismissive of the varied efforts that it takes to make things work that I cringe every time I hear it. Discussion, conferences, standards, coordination, etc all play an important role in making a software ecosystem useful. If there is a lesson, it may be that these other things shouldn't become so all consuming that they prevent actually producing useful software. Needless to say, by the standard of this statement I'm a wanker for bothering to point this out, and you folks are all wankers for repeating SteveC's bon mot. Best regards, -- ---+ -- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| President OSGeo, http://osgeo.org ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss Warning: Information provided via electronic media is not guaranteed against defects including translation and transmission errors. If the reader is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this information in error, please notify the sender immediately. ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] scale of FOSS projects
""Real artists ship. For everyone else, there is wanking." Folks, For the record, while I acknowledge a kernel of truth in this, I find the statement so elitist and dismissive of the varied efforts that it takes to make things work that I cringe every time I hear it. Discussion, conferences, standards, coordination, etc all play an important role in making a software ecosystem useful. If there is a lesson, it may be that these other things shouldn't become so all consuming that they prevent actually producing useful software. Needless to say, by the standard of this statement I'm a wanker for bothering to point this out, and you folks are all wankers for repeating SteveC's bon mot. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| President OSGeo, http://osgeo.org ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] scale of FOSS projects
On Thu, May 08, 2008 at 05:14:40PM -0500, P Kishor wrote: > On 5/8/08, Schuyler Erle <[EMAIL PROTECTED]> wrote: > > is that the number-one sine-qua-non of *any* potentially successful > > software project is *shipping working code*. > > Until a developer does that, the discussion of whether or not his/her > > project needs or deserves institutional/organizational support That is not what this discussion is about, though. (And the point seems self-evident, given this is a discussion about open source software projects, defined by having working code "in the wild") > Steve Coast (OSM) echoed the same sentiment very elegantly -- "Real > artists ship. For everyone else, there is wanking." > After a short hesitation, I have really come to appreciate it. Yup, > unless there is working code, everything else -- sponsorships, > organization, standards, committees, mailing lists -- is pointless. I really enjoyed the recent discussion here about non-developers contributions to open source projects and communities. Writing documentation and tutorials and maintaining translations, in particular. That code-jockey primacy attitude is potentially alienating to people wanting to contribute this kind of hard work. For many it is easy to write software. There is a lot of code out there, a lot of abandon-ware, projects that are "free" by a legal definition but with none of the supporting infrastructure that helps them to get used and to acquire a client base. At least Autodesk, for example, saw this and made bona fide effort to "build community", rather than dropping millions of lines of undocumented, hard-to-configure code onto the net, hoping an imaginary "open source community" would sprinkle pixie dust onto it, as Sun did at first - as if the time and goodwill of potential contributors were inexhaustible. There is this cultural pressure on "standards" to be marketing tools. Because of the government and military context for GIS, this pressure is particularly intense for us. It starts to loop back on itself somewhat like this, http://frot.org/on_standards/statements.html This does have a countereffect on innovation in software and it also probably does prevent "bona fide" standards developing in a natural way. As well as creating this terrific and largely justified backlash against some of the in-a-vacuum work done by OGC, ISO. (GeoDRM anyone) However the process of working things out by rough consensus and running code takes longer, business process says, "first to market -> "natural monopoly| de facto standard". It is unfortunate, because proper interoperability can be such a force for good - cf MetaCRS, and the future time and hassle that is going to be saved for many people, once the inevitable initial round of talking is done. I know, this argument has gone round and round in the past, and many are impatient with philosophising. I hope that philosophising can sometimes provide energysaving insight, or i wouldnt engage in it. But repeating "without code, you are nothing" grates on the nerves after a while. jo -- ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
RE: [OSGeo-Discuss] scale of FOSS projects
""Real artists ship. For everyone else, there is wanking." I'm going to add that to my book of favorite quotes. To bad it means I'm a wanker myself... Landon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of P Kishor Sent: Thursday, May 08, 2008 3:15 PM To: OSGeo Discussions Subject: Re: [OSGeo-Discuss] scale of FOSS projects On 5/8/08, Schuyler Erle <[EMAIL PROTECTED]> wrote: > On Thu, 2008-05-08 at 12:03 +0200, Mateusz Loskot wrote: > > > 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 important point that Fogel makes that I think is worth noting here > is that the number-one sine-qua-non of *any* potentially successful > software project is *shipping working code*. > > Until a developer does that, the discussion of whether or not his/her > project needs or deserves institutional/organizational support to > succeed further is moot. Steve Coast (OSM) echoed the same sentiment very elegantly -- "Real artists ship. For everyone else, there is wanking." After a short hesitation, I have really come to appreciate it. Yup, unless there is working code, everything else -- sponsorships, organization, standards, committees, mailing lists -- is pointless. Smart guy, that Coast. > > SDE > ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss Warning: Information provided via electronic media is not guaranteed against defects including translation and transmission errors. If the reader is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this information in error, please notify the sender immediately. ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] scale of FOSS projects
Tim Bowden wrote: On Thu, 2008-05-08 at 21:28 -0400, Miles Fidelman wrote: Michael P. Gerlek wrote: Or, to quote the IETF, "rough consensus and running code". Except that the reference is to the informal criteria for when one might even beginning to firm up a standard. In the IETF community - unlike pretty much every other standards body on the planet - there's a pretty strong insistence that there are multiple implementations of something, that an talk to each other, before even thinking about pinning down anything that looks like a standard. IMHO standards are just a fancy way of documenting the solution. Until you've build the solution, you don't understand the problem properly [1]. If you try and write your standard while your understanding of the solution space is underdeveloped, you'll end up with a pile of shite. We're in violent agreement here. Unfortunately, outside the IETF world, that's how standards are done - to just the effect you describe. But that's really besides the point - which is that that the IETF quote does not refer to the subject at hand (the cost/scale of software development, the degree to which institutional support is called for, and when support is needed) but to a philosophy of when to standardize communications protocols. Miles -- Miles R. Fidelman, Director of Government Programs Traverse Technologies 145 Tremont Street, 3rd Floor Boston, MA 02111 [EMAIL PROTECTED] 617-395-8254 www.traversetechnologies.com ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] scale of FOSS projects
On Thu, 2008-05-08 at 21:28 -0400, Miles Fidelman wrote: > Michael P. Gerlek wrote: > > Or, to quote the IETF, "rough consensus and running code". > > > Except that the reference is to the informal criteria for when one might > even beginning to firm up a standard. In the IETF community - unlike > pretty much every other standards body on the planet - there's a pretty > strong insistence that there are multiple implementations of something, > that an talk to each other, before even thinking about pinning down > anything that looks like a standard. > IMHO standards are just a fancy way of documenting the solution. Until you've build the solution, you don't understand the problem properly [1]. If you try and write your standard while your understanding of the solution space is underdeveloped, you'll end up with a pile of shite. Development is relatively fast and cheap, whilst standards are slow and expensive. Start with required outcomes, develop the solution, then document or "standardise" the solution. Put them in the wrong order, and you'll cripple both the solution and standard. [1] ESR explains it better than I can in catb: lesson 3 in http://catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s02.html. Regards, Tim Bowden > Pretty much everybody associated with the IETF is funded by nice, large > government contracts or has nice positions at large corporations, or > both. And pretty much all of the early code in and around the Internet > (and the ARPANET) was written by people with DARPA and NSF grants (when > they defined the TCP/IP protocol, Bob Kahn was either at BBN, my old > stomping grounds, or at DARPA, and Vint Cerf was a professor at > Stanford). The original reference implementation of TCP/IP - which > found it's way into an awful lot of different Unix variants - was > written by folks at BBN, again, funded by DARPA. Just read through the > library of RFCs at www.ietf.org and you'll find that most of the authors > have fairly serious organizational affiliations - they're doing the work > as part of their day jobs. > > Not that I'm complaining, mind you. Simply pointing out that leading > edge software tends to be written by folks with solid institutional > bases, and salaries, supporting them. > > Miles > ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] scale of FOSS projects
Michael P. Gerlek wrote: Or, to quote the IETF, "rough consensus and running code". Except that the reference is to the informal criteria for when one might even beginning to firm up a standard. In the IETF community - unlike pretty much every other standards body on the planet - there's a pretty strong insistence that there are multiple implementations of something, that an talk to each other, before even thinking about pinning down anything that looks like a standard. Pretty much everybody associated with the IETF is funded by nice, large government contracts or has nice positions at large corporations, or both. And pretty much all of the early code in and around the Internet (and the ARPANET) was written by people with DARPA and NSF grants (when they defined the TCP/IP protocol, Bob Kahn was either at BBN, my old stomping grounds, or at DARPA, and Vint Cerf was a professor at Stanford). The original reference implementation of TCP/IP - which found it's way into an awful lot of different Unix variants - was written by folks at BBN, again, funded by DARPA. Just read through the library of RFCs at www.ietf.org and you'll find that most of the authors have fairly serious organizational affiliations - they're doing the work as part of their day jobs. Not that I'm complaining, mind you. Simply pointing out that leading edge software tends to be written by folks with solid institutional bases, and salaries, supporting them. Miles -- Miles R. Fidelman, Director of Government Programs Traverse Technologies 145 Tremont Street, 3rd Floor Boston, MA 02111 [EMAIL PROTECTED] 617-395-8254 www.traversetechnologies.com ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
RE: [OSGeo-Discuss] scale of FOSS projects
Or, to quote the IETF, "rough consensus and running code". -mpg > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Paulo Marcondes > Sent: Thursday, May 08, 2008 4:20 PM > To: OSGeo Discussions > Subject: Re: [OSGeo-Discuss] scale of FOSS projects > > > > > Linus didn't write all of Linux. But he wrote enough for > it to be useful. > > > > Too much philosophy, not enough code. :) > > As Linus puts it: "talk is cheap..." =] > > > -- > Paulo Marcondes = PU1/PU2PIX > -22.915 -42.224 = GG86jc > ___ > Discuss mailing list > Discuss@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/discuss > ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] scale of FOSS projects
> > Linus didn't write all of Linux. But he wrote enough for it to be useful. > > Too much philosophy, not enough code. :) As Linus puts it: "talk is cheap..." =] -- Paulo Marcondes = PU1/PU2PIX -22.915 -42.224 = GG86jc ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] scale of FOSS projects
On May 8, 2008, at 3:32 PM, Miles Fidelman wrote: With rare exception (there are geniuses among us), it's pretty hard for one person to accomplish all that much, in a short amount of time, in odd hours outside their day job. At least none of the interesting projects I've been involved with required at least 6 months of full-time work show initial results - not a part-time endeavor. From tiny acorns do mighty oak trees grow. Mapserver started with a shape file -> image renderer and an HTML templating engine. Working, useful, code. From that, you can grow a community, who can grow the code. It might seem impossible to iteratively turn a Piper Cub into a 737, but in the software world it seems to happen all the time. Linus didn't write all of Linux. But he wrote enough for it to be useful. Too much philosophy, not enough code. :) P. ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] scale of FOSS projects
P Kishor wrote: On 5/8/08, Schuyler Erle <[EMAIL PROTECTED]> wrote: One important point that Fogel makes that I think is worth noting here is that the number-one sine-qua-non of *any* potentially successful software project is *shipping working code*. Until a developer does that, the discussion of whether or not his/her project needs or deserves institutional/organizational support to succeed further is moot. Steve Coast (OSM) echoed the same sentiment very elegantly -- "Real artists ship. For everyone else, there is wanking." After a short hesitation, I have really come to appreciate it. Yup, unless there is working code, everything else -- sponsorships, organization, standards, committees, mailing lists -- is pointless. Always one to provide a contrarian view, I've always felt that it always helps to start with a problem that's worth solving (speaking as an engineer), or something interesting to explore (from a scientific point of view). From there, funding, equipment, and a good team of people are good next steps. With rare exception (there are geniuses among us), it's pretty hard for one person to accomplish all that much, in a short amount of time, in odd hours outside their day job. At least none of the interesting projects I've been involved with required at least 6 months of full-time work show initial results - not a part-time endeavor. Mind you, I'm a systems engineer and project manager by trade - it's been a long time since I've been involved in a project that didn't have at least a small team, working a hard problem, over an extended amount of time. Ok, you can shoot at me now :-) Miles -- Miles R. Fidelman, Director of Government Programs Traverse Technologies 145 Tremont Street, 3rd Floor Boston, MA 02111 [EMAIL PROTECTED] 617-395-8254 www.traversetechnologies.com ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] scale of FOSS projects
On 5/8/08, Schuyler Erle <[EMAIL PROTECTED]> wrote: > On Thu, 2008-05-08 at 12:03 +0200, Mateusz Loskot wrote: > > > 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 important point that Fogel makes that I think is worth noting here > is that the number-one sine-qua-non of *any* potentially successful > software project is *shipping working code*. > > Until a developer does that, the discussion of whether or not his/her > project needs or deserves institutional/organizational support to > succeed further is moot. Steve Coast (OSM) echoed the same sentiment very elegantly -- "Real artists ship. For everyone else, there is wanking." After a short hesitation, I have really come to appreciate it. Yup, unless there is working code, everything else -- sponsorships, organization, standards, committees, mailing lists -- is pointless. Smart guy, that Coast. > > SDE > ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] scale of FOSS projects
Schuyler Erle wrote: On Thu, 2008-05-08 at 12:03 +0200, Mateusz Loskot wrote: 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 important point that Fogel makes that I think is worth noting here is that the number-one sine-qua-non of *any* potentially successful software project is *shipping working code*. It's also a good idea to release early and often. There is a temptation to bring a code with all possible issues smoothed away, but it defers release what might be bad if counted in months. -- Mateusz Loskot http://mateusz.loskot.net ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] scale of FOSS projects
On Thu, 2008-05-08 at 12:03 +0200, Mateusz Loskot wrote: > 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 important point that Fogel makes that I think is worth noting here is that the number-one sine-qua-non of *any* potentially successful software project is *shipping working code*. Until a developer does that, the discussion of whether or not his/her project needs or deserves institutional/organizational support to succeed further is moot. SDE ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] scale of FOSS projects
Howard Butler wrote: On May 6, 2008, at 3:10 PM, [EMAIL PROTECTED] 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 o
RE: [OSGeo-Discuss] scale of FOSS projects
Frank, You wrote: " I would *prefer* a project coming into incubation with six developers from six different organizations to one with six developers all from one organization." Well put. You said in one sentence what I was trying to say in four (4) paragraphs. Landon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Frank Warmerdam Sent: Tuesday, May 06, 2008 8:45 PM To: OSGeo Discussions Subject: Re: [OSGeo-Discuss] scale of FOSS projects Jo, I'm having trouble responding to your email, I think since it touches on a number of points, and perhaps just because I mostly agree with what you have said. So instead, I will just assert a few loosely related points that come to mind after reading it. 1) I still fundamentally believe a bunch of enthusiastic and reasonably skilled people can build a project with impact without the explicit backing of one promoting enterprise. 2) For projects coming out of a "single backer" situation into OSGeo we offer a level playing field to help turn the project into a fair community where all contributors have some assurance of having an influence. 3) For projects coming out of a more chaotic origin - many contributors, or at least no major enterprise associated with backing the project - we offer some degree of "organizational legitimacy" that can be helpful in selling their project to risk averse enterprise type users. 4) While this one of the things I like about geospatial open source software is the participation of some folks doing it more for fun than profit, we are still *mostly* an industrial software sector. We make software used for all sorts of gritty business / commerce / government / science as a sort of "industrial IT input" to other things. For this reason, I feel it is inevitable that a substantial part of what we do will be about serving various industrial needs. This implies our primary users will be commercial, government and academic/research - fields dominated by organizations of various sizes that can be considered enterprises. 5) I absolutely do *not* think entrance into incubation for a project should be based on having a substantial enterprise backing the project. However, to avoid being swamped in small immature projects, I think it is reasonable to hold out for projects that are already reasonable mature, have a substantial supporting community and are of a quality and utility that we think will reflect well on OSGeo when we promote it. I would *prefer* a project coming into incubation with six developers from six different organizations to one with six developers all from one organization. 6) As Cameron mentions, consolidation is to some extent to be expected in this and all software sectors. I think that's ok and natural. We have quite a few desktop GIS software packages now for instance, and one imagines that while some will grow stronger and grow, others will wither. 7) On the other hand, I think there are other sectors where a small projects can still fill a particular need without being big, heavily backed, etc. Utility programs, web mashups, mobile location aware applets, etc. It behooves OSGeo to understand that these things play a role even if they don't need our process-heavy project steering committees, incubation, etc. Lets not hesitate to celebrate, and promote them as appropriate. Ultimately, I'm left feeling that there is no explicit action item here. The universe will continue to unfold, projects will bloom and die, consolidation and ferment will both happen. We don't need to predict it all, or guide it. We just help where we can, provide services where it makes sense, and watch it unfold. But then, I'm not really a very good "big picture" kind of guy. A little too laid back in some ways. :-) Best regards, -- ---+ -- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| President OSGeo, http://osgeo.org ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss Warning: Information provided via electronic media is not guaranteed against defects including translation and transmission errors. If the reader is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this information in error, please notify the sender immediately. ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] scale of FOSS projects
Miles Fidelman wrote: ... I think I've made this comment before, but it probably bears repeating: History is a useful indicator. As far as I can tell, most "really successful" open source projects started out as efforts that had some serious funding behind them, or something that allowed the initial developer(s) some running room to get a project started. The examples of "really successful open source projects" that come to mind: ... Linux: Started as a thesis project. Filled a critical niche (free alternative to Unix) - though it's still unclear why the BSD variants didn't end up dominating this niche. GNU tools: Stallman, and a cast of thousands - with MIT providing a home. ... At the moment, I can't think of any "really successful open source projects" that didn't have their origins with "a network of partly-funded enthusiast contributors" where the originator didn't have some form of organizational home and/or a funding stream for the first few releases of the software. Miles, I think that Linux and the GNU tools are very weak examples of your point. Sure, Linux may have had some limited sort of financial support as a student, but if a student building an operating system (and talking his professor into letting it be his thesis effort) doesn't count as grassroots then what does? Does grassroots really have to imply homeless people living on the street and writing free software on the computers at their local internet cafe? Likewise, Richard Stallman was provided some office space at MIT, but was not, to the best of my knowledge, under salary for the first several years he worked on the GNU tools. Even if he was, letting a researcher / lab assistant do a bunch of free stuff on work time isn't the same (in my mind) as organized institutional support. I think the distinction between "enterprise backed" vs "grassroots" projects would be more like the comparison between MapGuide (enterprise backed) and QGIS (a loose association of people, some of who are doing the work on company time). Even MapServer, while it has some institutional support from UMN, NASA, etc, was much more skunkworks than it was a strategically planned effort of one enterprise. If the enterprise backed vs. grassroots comparison is to be meaningful I think we have to avoid being to reductionist about what counts as enterprise backed. Having a job (in which you sneak in a bit of free software work) isn't the same as being enterprise backed. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| President OSGeo, http://osgeo.org ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
RE: [OSGeo-Discuss] scale of FOSS projects
> At the moment, I can't think of any "really successful open source projects" that didn't have their origins with "a network of partly-funded enthusiast contributors" where the originator didn't have some form of organizational home and/or a funding stream for the first few releases of the software. > Now, if anybody has a good example of a more grass roots project that has survived - please, some examples would be a great contribution to this discussion. It has gone through some major changes, but GeoTools might fit into the surviver without initial funding class of OSS and it's FOSS4G too :-) Best wishes, Andy http://www.geog.leeds.ac.uk/people/a.turner/ ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] scale of FOSS projects
Howard Butler wrote: On May 6, 2008, at 3:10 PM, [EMAIL PROTECTED] 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. By serious organization, I don't mean a rickety scaffolding of bureaucracy. I think I've made this comment before, but it probably bears repeating: History is a useful indicator. As far as I can tell, most "really successful" open source projects started out as efforts that had some serious funding behind them, or something that allowed the initial developer(s) some running room to get a project started. The examples of "really successful open source projects" that come to mind: Sendmail: University based, lots of R&D funding. Eventually led to a private company that maintains the open source version and provides commercial versions. Arguably the most successful open source project ever. Apache: Started as the NCSA web daemon, lots of government R&D funding. It has already been widely distributed and adopted by the time it stopped being research. Adopted by key members of its user community. A good competitor for the most successful open source project ever. Linux: Started as a thesis project. Filled a critical niche (free alternative to Unix) - though it's still unclear why the BSD variants didn't end up dominating this niche. GNU tools: Stallman, and a cast of thousands - with MIT providing a home. Sympa (mailing list manager): Still largely funded by a consortium of French universities. And from the geospatial domain, GRASS: Originally developed by the US Army. At the moment, I can't think of any "really successful open source projects" that didn't have their origins with "a network of partly-funded enthusiast contributors" where the originator didn't have some form of organizational home and/or a funding stream for the first few releases of the software. Now, if anybody has a good example of a more grass roots project that has survived - please, some examples would be a great contribution to this discussion. Miles -- Miles R. Fidelman, Director of Government Programs Traverse Technologies 145 Tremont Street, 3rd Floor Boston, MA 02111 [EMAIL PROTECTED] 617-395-8254 www.traversetechnologies.com ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] scale of FOSS projects
On May 6, 2008, at 3:10 PM, [EMAIL PROTECTED] 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. By serious organization, I don't mean a rickety scaffolding of bureaucracy. OSGeo's incubation process prescribes a bureaucracy (project steering committees) onto projects to be accepted as part of incubation. Some projects within OSGeo embrace this whole heartedly, while others continue their lieutenants' model or dictatorship due to those being active ending up making the decisions -- with the checks and balances the PSC approach hopes to achieve (no project as far as I know has had such a knock-down, drag out to actually test this assumption). The incubation process tries to prescribe the PSC model because it desires that incoming projects "be organized" in such a way as to be able to keep its own house in order in the event of problems that affect its open development. I think development organization is what sets apart one blob of source code from another where both might do the same thing. 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. 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. 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? 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. Without it, however, interested parties have no real way to empower themselves into becoming active contributors to the project without drawing significant load from the active developers. Because developers come and go to a project, this process repeats itself unless the project itself makes it possible for people to bootstrap themselves -- a long term investment unlikely to pay off at all in the short term. 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 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. MapServer and Mapnik overlap in a lot of conceptual areas, and there's plenty of room for both. What there isn't plenty of is C/C++ developers who wish to develop open source GIS rendering software for web applications. I would argue that if there are any monopolies to be gained in open source software development that they are monopolies of developers' attention, not monopolies of software products. Howard ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] scale of FOSS projects
Jo, I'm having trouble responding to your email, I think since it touches on a number of points, and perhaps just because I mostly agree with what you have said. So instead, I will just assert a few loosely related points that come to mind after reading it. 1) I still fundamentally believe a bunch of enthusiastic and reasonably skilled people can build a project with impact without the explicit backing of one promoting enterprise. 2) For projects coming out of a "single backer" situation into OSGeo we offer a level playing field to help turn the project into a fair community where all contributors have some assurance of having an influence. 3) For projects coming out of a more chaotic origin - many contributors, or at least no major enterprise associated with backing the project - we offer some degree of "organizational legitimacy" that can be helpful in selling their project to risk averse enterprise type users. 4) While this one of the things I like about geospatial open source software is the participation of some folks doing it more for fun than profit, we are still *mostly* an industrial software sector. We make software used for all sorts of gritty business / commerce / government / science as a sort of "industrial IT input" to other things. For this reason, I feel it is inevitable that a substantial part of what we do will be about serving various industrial needs. This implies our primary users will be commercial, government and academic/research - fields dominated by organizations of various sizes that can be considered enterprises. 5) I absolutely do *not* think entrance into incubation for a project should be based on having a substantial enterprise backing the project. However, to avoid being swamped in small immature projects, I think it is reasonable to hold out for projects that are already reasonable mature, have a substantial supporting community and are of a quality and utility that we think will reflect well on OSGeo when we promote it. I would *prefer* a project coming into incubation with six developers from six different organizations to one with six developers all from one organization. 6) As Cameron mentions, consolidation is to some extent to be expected in this and all software sectors. I think that's ok and natural. We have quite a few desktop GIS software packages now for instance, and one imagines that while some will grow stronger and grow, others will wither. 7) On the other hand, I think there are other sectors where a small projects can still fill a particular need without being big, heavily backed, etc. Utility programs, web mashups, mobile location aware applets, etc. It behooves OSGeo to understand that these things play a role even if they don't need our process-heavy project steering committees, incubation, etc. Lets not hesitate to celebrate, and promote them as appropriate. Ultimately, I'm left feeling that there is no explicit action item here. The universe will continue to unfold, projects will bloom and die, consolidation and ferment will both happen. We don't need to predict it all, or guide it. We just help where we can, provide services where it makes sense, and watch it unfold. But then, I'm not really a very good "big picture" kind of guy. A little too laid back in some ways. :-) Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| President OSGeo, http://osgeo.org ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] scale of FOSS projects
[EMAIL PROTECTED] 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. The other way is to do something so obviously "correct" that a community clusters around it :-) I wonder about a cultural climate generally - NOT an OSGeo-specific one - in which projects have to have a certain amount of institutional support in order to even get *into* the incubation process, let alone graduate out of it. I have found it an interesting trade off; institutional support keeps the GeoTools project alive and very busy. None of those institutions are concerned with graduating from the incubation process directly (ie graduation does not effect any deadlines) - thus work is proceeding very slowly on volunteer time. 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? That is true; but there is still plenty of space for collaboration (and competition) - see the recent discussion on a shared Java referencing project. A situation where a very few projects make it into broad and stable use, and a very many just spike, flutter and fade - well perhaps the open source ecology has always looked this way. But the more a few projects gather monopoly momentum, the less likely it is that newer projects can build up sufficient scale to challenge them. The kind of incubation process run by OSGeo, ASF, then serves to accentuate and promote this. One thing we stress in the incubation process (possibly as a counter to the effect you mention) is some kind of open development process. That is within each project we expect a procedure to allow new contributors (and contributions). If this is inevitable, why? Is innovation less possible outside the "enterprise"? Is this even a FOSS problem or a computing-in-the-broad one? It is a broad problem of "mind share", I recently ran across a proposal to use cocoon to do some web user interface work; the technology is certainly capable and even pretty - but web front ends have progressed so away from XSLT that cocoon does not represent a fashionable alternative (ie no "mind share"). I would appreciate hearing any thoughts that this provoked. Happy hacking, Jody ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
RE: [OSGeo-Discuss] scale of FOSS projects
Puneet, I chose my words poorly. This is what happens when I am in a hurry. :] A fork is the ultimate evil in the sense that it diverts resources like time and money. "United we stand, divided we fall." It is the ultimate good in the sense that it prevents any one organization for asserting complete control over a project. So I guess it all depends on one's perspective. It would have been better for me to say that the THREAT of a fork is very powerful, but that an actual fork is usually a bad thing for the community at large. There are exceptions to this rule. My opinion is, of course, colored by my own personal experiences. Imagine what UDig and OpenJUMP might have accomplished if they were a single program now? Landon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of P Kishor Sent: Tuesday, May 06, 2008 1:44 PM To: OSGeo Discussions Subject: Re: [OSGeo-Discuss] scale of FOSS projects On 5/6/08, Landon Blake <[EMAIL PROTECTED]> wrote: . > > I think the ability to fork open source code puts a real limitation on > the ability of any one entity to create an "open source monopoly". Forks > are the ultimate evil in the open source world, but they sometimes > become the necessary "nuclear option". .. I am finding it difficult to add up the above statement. Is forking "evil" (a very strong word especially when prefixed with "ultimate") or is it good (as implied by "necessary" in front of "nuclear option')? > One open source program that I can think of that survived a > serious fork is Inkscape/Sodipod, with Inkscape now being what > I would call an successful open source project. As described above, it seems to me that forking is the ultimate check-and-balance device which ensures longevity, as much as possible, of an OS project, and protects against lock-in. In that sense, it is the "ultimate good." -- Puneet Kishor http://punkish.eidesis.org/ Nelson Institute for Environmental Studies http://www.nelson.wisc.edu/ Open Source Geospatial Foundation (OSGeo) http://www.osgeo.org/ ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss Warning: Information provided via electronic media is not guaranteed against defects including translation and transmission errors. If the reader is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this information in error, please notify the sender immediately. ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] scale of FOSS projects
On 5/6/08, Landon Blake <[EMAIL PROTECTED]> wrote: .. > > I think the ability to fork open source code puts a real limitation on > the ability of any one entity to create an "open source monopoly". Forks > are the ultimate evil in the open source world, but they sometimes > become the necessary "nuclear option". .. I am finding it difficult to add up the above statement. Is forking "evil" (a very strong word especially when prefixed with "ultimate") or is it good (as implied by "necessary" in front of "nuclear option')? > One open source program that I can think of that survived a > serious fork is Inkscape/Sodipod, with Inkscape now being what > I would call an successful open source project. As described above, it seems to me that forking is the ultimate check-and-balance device which ensures longevity, as much as possible, of an OS project, and protects against lock-in. In that sense, it is the "ultimate good." -- Puneet Kishor http://punkish.eidesis.org/ Nelson Institute for Environmental Studies http://www.nelson.wisc.edu/ Open Source Geospatial Foundation (OSGeo) http://www.osgeo.org/ ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] scale of FOSS projects
Jo, consolidation is a natural progression in any market, even Open Source. This is driven by user requirements, which in turn drives resources. Users in general want maximum functionality for their investment. They want low risk. They want future proofing. This is usually achieved by selecting the best, most successful project in their niche. So the rich projects get richer, and poor get poorer. Note also that the cost of reviewing all applications to suite your business needs is expensive. So it is valuable for users to have a "quality stamp" applied to projects to help focus their search. At the moment, OSGeo is providing the "quality stamp" for OSGeo projects. [EMAIL PROTECTED] wrote: Increasingly the projects that OSGeo accepts into incubation are ones that have been created and supported by a large organisation - a company or agency - now seeking to get more people from "outside", who they are not directly supporting, properly involved. 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. (There *are* noble exceptions, but those are projects which either have been around for a good long while, or which are libraries reused and maintained by several projects as "collective infrastructure") "This project is mature enough to be used for the task, without fear it's going to disappear without a trace... that's part of what OSGeo incubation is all about" I wonder about a cultural climate generally - NOT an OSGeo-specific one - in which projects have to have a certain amount of institutional support in order to even get *into* the incubation process, let alone graduate out of it. I heard this complaint from a few Apache Software Foundation people a couple of years ago. They were getting so many applicants for incubation - and had several dozen projects in the incubator at once - the only was to really assess quality going in, and commitment to future maintenance, was to focus on projects with 40+ committers and existing corporate support. (This "culture change" in turn led to core ASF'ers keeping their newer projects *out* of the foundation. Now there are more "ASF brings you Yahoo!'s..." projects like http://hadoop.apache.org/) 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? A situation where a very few projects make it into broad and stable use, and a very many just spike, flutter and fade - well perhaps the open source ecology has always looked this way. But the more a few projects gather monopoly momentum, the less likely it is that newer projects can build up sufficient scale to challenge them. The kind of incubation process run by OSGeo, ASF, then serves to accentuate and promote this. If this is inevitable, why? Is innovation less possible outside the "enterprise"? Is this even a FOSS problem or a computing-in-the-broad one? (Please note i *don't* intend any criticism of the projects that are coming through incubation at the moment. It's great news that latlon.de now see more potential value in deegree becoming an OSGeo project than in being marketed as a latlon project. hooray!) I would appreciate hearing any thoughts that this provoked. jo -- Cameron Shorter Geospatial Systems Architect Tel: +61 (0)2 8570 5050 Mob: +61 (0)419 142 254 Think Globally, Fix Locally Commercial Support for Geospatial Open Source Solutions http://www.lisasoft.com/LISAsoft/SupportedProducts.html ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
RE: [OSGeo-Discuss] scale of FOSS projects
Jo, You have touched on an issue dear to my heart. I have a lot of work to do this afternoon, so I can't babble on as I normally do. But, I can't resist one or two short comments. Jo 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 won't disagree with this perspective, I will only offer this point for consideration: An open source project appears more stable to me if it is supported by a "network of party-funded enthusiasts contributors" than a single corporate entity. Why? What happens when that corporate entity is sold, goes out of business, or looses interest in the open source project, or looses funding for the open source project? Users have very little control over the corporate decision making process. An open source project supported by a diverse group of volunteers has a much greater chance of surviving in my humble opinion. OpenJUMP would be one example of this. If it had depended on its original corporate sponsor for survival it would have died a long time ago. I think the ability to fork open source code puts a real limitation on the ability of any one entity to create an "open source monopoly". Forks are the ultimate evil in the open source world, but they sometimes become the necessary "nuclear option". One open source program that I can think of that survived a serious fork is Inkscape/Sodipod, with Inkscape now being what I would call an successful open source project. Landon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, May 06, 2008 1:11 PM To: discuss@lists.osgeo.org Subject: [OSGeo-Discuss] scale of FOSS projects Increasingly the projects that OSGeo accepts into incubation are ones that have been created and supported by a large organisation - a company or agency - now seeking to get more people from "outside", who they are not directly supporting, properly involved. 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. (There *are* noble exceptions, but those are projects which either have been around for a good long while, or which are libraries reused and maintained by several projects as "collective infrastructure") "This project is mature enough to be used for the task, without fear it's going to disappear without a trace... that's part of what OSGeo incubation is all about" I wonder about a cultural climate generally - NOT an OSGeo-specific one - in which projects have to have a certain amount of institutional support in order to even get *into* the incubation process, let alone graduate out of it. I heard this complaint from a few Apache Software Foundation people a couple of years ago. They were getting so many applicants for incubation - and had several dozen projects in the incubator at once - the only was to really assess quality going in, and commitment to future maintenance, was to focus on projects with 40+ committers and existing corporate support. (This "culture change" in turn led to core ASF'ers keeping their newer projects *out* of the foundation. Now there are more "ASF brings you Yahoo!'s..." projects like http://hadoop.apache.org/) 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? A situation where a very few projects make it into broad and stable use, and a very many just spike, flutter and fade - well perhaps the open source ecology has always looked this way. But the more a few projects gather monopoly momentum, the less likely it is that newer projects can build up sufficient scale to challenge them. The kind of incubation process run by OSGeo, ASF, then serves to accentuate and promote this. If this is inevitable, why? Is innovation less possible outside the "enterprise"? Is this even a FOSS problem or a computing-in-the-broad one? (Please note i *don't* intend any criticism of the projects that are coming through incubation at the moment. It's great news that latlon.de now see more potential value in deegree becoming an OSGeo project than in being marketed as a latlon project. hooray!) I would appreciate hearing any thoughts that this provoked. jo -- ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss Warning: Information provided via electronic media is not guaranteed against defects including translation and transmission errors. If the reader is not the intended recipient, you are h
