<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><div class="im"><blockquote type="cite"><div dir="ltr">I was able to follow the Features page reasonably
well, but since the text is describing "company" policy, and I
suppose a company product, perhaps it belongs on the company
website?</div>
</blockquote>
</div>interesting idea. I wanted to have a maximum of transparency, and a
minimum of links to the commercial site, moving the feature list
would require such a link, given the understandable interest of the
community: "I have heard about this feature, is it community or
enterprise?" So I felt this is the most open, accessible way of
dealing with it.<br></div></blockquote><div><br></div><div style>It is up to you and your community how you want to balance. If you watch the OSGeo board mailing list you can see the IRS has been getting stuck over exactly this kind of balance between open source (for the public good) and open source (product/user license agreement, or vendor / customer contract).</div>
<div style><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
If moving the feature matrix is requested by mentor and OSGeo, we
would do it with a corresponding hint, so I am curious about
opinions.</div></blockquote><div><br></div><div style>I am curious as well, most other projects I have seen have one section pointing off to commercial support and products. But often it is the other way commercial and product websites pointing out the open source components they use.</div>
<div style><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
<div class="im"><blockquote type="cite"><div dir="ltr"><div>The other thing to consider is when the community
creates functionality that is not needed in a commercial
bundle. Perhaps it does not meet QA, documentation, or
operational standards? Or simply does not solve a problem of
interest to your customers.<br></div></div></blockquote></div><div class="im">
<br></div>
hm, we gladly accept contributions, but only if the meet QA we have
established in the open-source project. I would not want to give up
what we have achieved in terms of quality. <br>
It's also a matter of keeping things simple I believe.<br></div></blockquote><div><br></div><div style>Yep, that is half the battle of incubation - documenting what hoops people have to jump through to contribute to the project. And then being fair and making sure your existing contributors jumps through the same hoops.</div>
<div style><br></div><div style>So I repeat OSGeo Incubation is not supposed to change how your project does business, it is supposed to document how your project does business. Things such as Benevolent Dictator model are usually caught during application.</div>
<div style><br></div><div style><div>Note: the hoops need to be open to "outside" involvement. We are trying to avoid the situation JUMP found itself in, where although it was an open source project it was "pay to play" (you would need to hire staff time to review your patch). That does not mean everything is cost-free - GeoNetwork for example sorted out most of their development roadmap in person at a gathering organised by the key stakeholers. So while anyone could attend, they would need sort out their own travel. I think OSSIM was also replying on in person breakfast meetings, and I get the impression a lot of gvSIG decision making happens at their conferences.</div>
<div><br></div></div><div style>Jody</div></div></div></div>