[mapguide-internals] RE: Project Sponsorship
Kenneth Skovhede, GEOGRAF A/S
ks at geograf.dk
Mon Nov 24 03:14:31 EST 2008
I find that you and Zac are right to the point.
I have tried many times over to debug something in MapGuide, but there
is simply
no core documentation avalible. The internal division in request and
response packets
make sense from a performance perspective, but since there is no
documentation
on what the request/response flow is, it is very difficult to trace a
package.
I have requested such documentation before, but have not seen it yet.
A mentor would be nice, but for starters, a "core developer guide" would be
more helpfull (to me at least).
Regards, Kenneth Skovhede, GEOGRAF A/S
Andy Morsell skrev:
> I completely agree that the majority of sponsorship interest from community
> members will be around targeted bug fixes and feature development. I also
> agree that right now we're very limited by a small group of core developers
> as being our only resource to assist in getting the bugs fixed and the
> features developed. Most MapGuide users simply do not have the skills to do
> core development work so are reliant on the existing developer group. The
> existing developers are clearly starting to get frustrated that not many
> other developers are jumping in, but it seems that there just aren't that
> many folks with the right skills to help out in the ways that are needed.
>
> I have actually offered to contribute money more than once (case in point,
> $500 to Frank's plea for help) to specific items and nobody ever took me
> (and others) up on these offers, regardless of whether there was an official
> sponsorship model in place. Based on this, I'm not overly optimistic that
> it will have much effect unless the individual tasks are able to be treated
> like profitable projects by the developers. Much the same way it makes
> sense for DM Solutions and other consultants to get paid by clients to do
> development and contribute it back to the project. Only in this case, it
> wouldn't necessarily be for a specific client, but rather for the project
> itself.
>
> The bottom line: it hasn't seemed to matter how much money we've been
> willing to throw at the project if we don't have the resources to do the
> work...... Perhaps the sponsorship program will draw some worthy developers
> out of the woodwork, so I think it's worth continuing to explore it.
>
>
> Andy Morsell, P.E.
> Spatial Integrators, Inc.
> www.SpatialGIS.com
>
>
> -----Original Message-----
> From: mapguide-internals-bounces at lists.osgeo.org
> [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Zac Spitzer
> Sent: Sunday, November 23, 2008 6:00 PM
> To: MapGuide Internals Mail List
> Subject: Re: [mapguide-internals] RE: Project Sponsorship
>
> Generally speaking, aside from general sponsorship for the general
> stuff (build infrastructure), one of the main things
> where i see organisations being interested in sponsorship is very
> targeted bug/feature development.
>
> To take the example of a company or individual deciding for example
> they really need the GDAL FDO provider fixed
> and deciding they want to commit their own resources to fixing this,
> they really need mentoring
>
> The classic example was Frank Warmerdam putting his hand up to resolve
> this bug and asking for assistance from
> a mapguide developer. His requests went unanswered (AFAIKT) and this
> issue remains unresolved.
>
> A similiar example is the CMAKE build process which Helio was (is) working
> on
>
> Currently, nearly all the development on Mapguide is being done via
> Autodesk employees and as a result Autodesk
> have a strong vested interest in the project, but this also forms a
> barrier for external developers to get involved in the project.
>
> Jason's idea of a portal manager, is being performed by the community
> at them moment and that is working reasonably well.
>
> What is really needed is a something like a 'development mentor /
> champion' available within the Autodesk team who can
> assist / guide external developers and capture this information along
> the way, either via wiki articles or via the mailing list.
>
> Making the build process simpler is critical, when a developer can
> simply check the code out and build it and start hacking,
> they are much more likely to actually start developing and
> contributing code back to the project.
>
> The current complexity of the build process means that a lot of people
> start, getting stuck in build issues and loose interest.
>
> http://how2map.blogspot.com/2008/11/mapguide-shaping-up.html
>
> z
>
>
>
> On Mon, Nov 24, 2008 at 11:53 AM, Jason Birch <Jason.Birch at nanaimo.ca>
> wrote:
>
>> I'd prefer to work out the details before going to vote; two votes will
>>
> just slow down the process.
>
>> Looking at the GDAL and OpenLayers examples, I believe that there are
>>
> quite a few differences in what we could feasibly apply the funds toward at
> this point, primarily because of our developer/user mix. However, some of
> the important tenets (PSC directs the use of funds, sponsors get full
> reporting on use of funds and feedback through annual questionairres, etc)
> feel right to me. I also think that we should have a mechanism for
> sponsorship funds to be earmarked for specific PSC-approved projects,
> assuming that at some point we find developers within the community
> interested in undertaking this kind of work.
>
>> Apart from the necessary infrastructure for continuous builds and
>>
> installer packaging, why do we need sponsorship, goals and specifics? I've
> got some thoughts, but I'd like to hear from everyone.
>
>> Goals:
>> - Increase the level of community participation in the MapGuide
>>
> development process
>
>> - Enhance the quality of the project's communications (announcements,
>>
> tickets, release transparency, etc)
>
>> - Ensure that project is approachable by new users, especially in the
>>
> areas of documentation, code samples, initial install experience, etc.
>
>> Potential uses (examples only, actual PSC-approved expenditures may
>>
> differ):
>
>> - Maintain project-specific infrastructure necessary to support a fully
>>
> open development environment -- OSGeo takes care of things like Trac, SVN,
> and downloads very well for us, but seems to be under-resourced for
> supporting a continuous build framework, especially for projects such as
> ours which require strong Windows support.
>
>> - Partial funding for a portal manager, ensuring that tickets are
>>
> followed up, email issues are referred to the Trac system where appropriate,
> new releases are tagged with best possible information on date, etc.
>
>> - Creation and maintenance of MapGuide installers/packages for a wider
>>
> range of operating systems
>
>> I'm sure there is much more, and maybe some of these aren't in sync with
>>
> everyone's thinking. There is also some thought to be given to what
> sponsors can expect from this, other than higher quality software and
> community recognition.
>
>> Please let post to the group with your items, etc. Clearly separate goals
>>
> from potential uses, and ensure that the uses can be tied back to specific
> goals. Once we get a bit of cohesiveness, this should all go in a wiki for
> collaborative editing.
>
>> For reference:
>>
>> http://www.gdal.org/sponsorship.html
>> http://openlayers.org/sponsorship/
>>
>> Jason
>>
>> ________________________________
>>
>> From: Paul Spencer
>> Sent: Sat 2008-11-22 8:31 AM
>> Subject: Re: [mapguide-internals] RE: Project Sponsorship
>>
>> I'm also in favour of this. The OpenLayers team has just finished a
>> lengthy discussion on sponsorship and has developed some guidelines of
>> how the sponsorship stuff will work for them (largely based on the
>> GDAL experience and example). I think we will need to develop a
>> similar set of guidelines for sponsorship for MGOS and have the
>> community and the PSC discuss it before we can formally go that route,
>> but the PSC could vote to agree (or not) on sponsorship in general
>> with the details to be decided on later by a second vote.
>>
>>
>> _______________________________________________
>> mapguide-internals mailing list
>> mapguide-internals at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>>
>>
>>
>
>
>
>
More information about the mapguide-internals
mailing list