Re: [oor-forum] OOR Sustainability

[Cameron Ross <cross@xxxxxxxxxxxx>]

Hi Adam,

These are all really good points.  I think that the sustainability of SUMO and Sigma can provide some excellent guidance for the OOR.  

On Fri, Sep 17, 2010 at 10:19 AM, Adam Pease <adampease@xxxxxxxxxxxxx> wrote:

Hi Cameron,
 This is an important point.   While there are many models of
sustainability, there have been a number of factors in the
sustainability of SUMO (and Sigma) over the past 10 years.

- Have a champion.  No idea or project succeeds without one committed
person to drive it.  Funding comes and goes, but I view work with SUMO
as my most marketable asset, so I'm committed for the long term.

Pursuing all avenues - government and commercial funding, as well as
volunteer academic work on SUMO has kept it moving forward.

I've used a similar model for some of the initiatives I've worked on and one of the challenges I've faced is that evangelizing is a huge effort.  This is not necessarily a bad thing, I love doing it, but how do you fund the champion to do the evangelizing... its not a deliverable that is often covered by most funding sources.  Perhaps you have some suggestions around funding the champion(s).

 

- Open source.  Ontology, and particularly formal ontologies in first
order logic, are still a bit speculative as far as the marketplace is
concerned.  This was dramatically more so in the year 2000.  Giving away
SUMO has led to its adoption on many projects.  Academic projects
certainly would not have paid for it, and it is that body of experience
in validating SUMO that has led to commercial use.

I think there's consensus in the group on releasing both the OOR content and source code under open licenses.  I also believe that many in the group would agree that supporting commercial use is a good thing (or it is at least acceptable).  I think that the main problem will be in deciding which licenses we will choose.  Here's my two cents...

As a software developer that has contributed to several open source projects, I have some relatively strong opinions on open source licenses.  There is no single license that view as being the one "true" open source license.  Rather, it depends on the situation at hand.  Here are some of the rules I go by:

1)  If I invest a non-trivial amount of time on an open source project then it just has to have a commercial play for me... period.  As they say, there is no free lunch, and since I work for a small company, I need to make every hour countso that we can keep the lights on, pay our mortgages, feed our families etc.  It's just reality... take this ability away and the investment must be made elsewhere.  Note, however, that some investments can be strategic and longer term, which is what the Samian Platform and COLORE project represent for Kojeware.

2) If I invest a non-trivial amount of time on an open source project then I want to be able to use this project's code within my proprietary products (see #1).  A significant part of our business model is selling software products.  We want to share the development costs of building software infrastructure that would be of use to others, but we need to be able to sell software that uses this infrastructure.  We're doing this now with the Samian Platform.  It's an open source project that we've funded, but we would like to share future development costs with a broader community.   We use Samian within our commercial Ontology Development Environment product.  The project license must support this kind of commercial application, which is why Kojeware can't invest in projects that adopt the GPL.  I suspect that Articulate can live with the GPL because its business model is based on consulting services (Adam, please correct me if I'm wrong).  However, IMHO the OOR must support both product and service models.

3) I am not a fan of the dual licensing model whereby software is released under GPL for open source projects and a proprietary license for commercial applications.  I think that this model imposes a barrier to recruiting contributors.  Why would I write software and then give it to you so that you can go and sell it?  So, if down the road I want to use the code I've written within a commercial app, I will have to buy a license from you!  I think that most developers are smarter than that and won't contribute to the project.

4) Gift licensing is a reasonable alternative from my perspective.  However, as Bruce Perens noted, it can be a barrier to recruiting other developers (Bruce indicated that he wouldn't contribute to projects that release under a gift license... or maybe he just meant BSD... I can't remember).   The problem here is similar to my concern with the dual licensing model mentioned above in that a developer gives their work to someone else who can make money on it.  However, I see gift licensing as an improvement over dual licensing in that at least the code remains open and I can use it within my own future commercial applications without having to pay someone else.  I just can't stop you from making money with it.

5) I like the Eclipse Public License (EPL) because it's "something in-between" a gift license and the GPL.  That is, you are still required to release derivative works under the EPL, but you can use the code within commercial applications.  I believe that this is the best model to support open source infrastructure that is intended to support a software ecosystem and there are some great examples, the Eclipse Tool Platform for one. 

6) I still don't have a opinion on which option is best for licensing ontology content.  However, based on Jon Wilbank's comments yesterday, it is clear that we have to balance ontology "interoperability" with "openness".  Interoperability seems best serviced with something like CC-by, whereas openness seems best serviced with something like CC-by-sa.  Given a choice between the two, I would lean towards interoperability. 

- Good technical solution.  Obviously, what's being produced has to
work, and be broadly applicable to get traction with a group of
committed users.

I agree.  Broad applicability seems like it will be key to a healthy ecosystem for OOR.

- Continued change and evolution.  The product has to respond to the
marketplace.  Good customer service in making changes and bug fixes is
important.  So is a bit of "push" in creatively adding new features and
components.

Absolutely!  Again, the ecosystem model leaves thinks free so that niche players within the ecosystem can differentiate and innovate as the market evolves.

 

Adam

On Fri, 2010-09-17 at 08:43 -0400, Cameron Ross wrote:
> In yesterday's ONTOLOG session on IPR, Alan Rector summarized his
> experiences with the GALEN and SNOMED projects.  During his
> presentation Alan brought up the issue of sustainability (i.e. the
> ability for a project to continue to survive once its initial seed
> funding has been depleted).  I'm not aware of any discussion related
> to OOR sustainability as yet.  I believe this is a problem as we are
> starting to talk seriously about licensing models for OOR and the
> licensing models we choose will have a definite impact on the business
> models that the OOR will be able to support.  Presumably, the long
> term sustainability of the OOR will be predicated on its licensing
> models.  I'd like to start a thread on this topic so that we can
> elicit input from the OOR group prior to our final session on IPR on
> September 30th.
>
>
> What are the groups thoughts in this regard?
>
>
> Cameron.
>
> --
> Kojeware Corporation

> _________________________________________________________________
> Message Archives: http://ontolog.cim3.net/forum/oor-forum/
> Subscribe: mailto:oor-forum-join@xxxxxxxxxxxxxxxx
> Config/Unsubscribe: http://ontolog.cim3.net/mailman/listinfo/oor-forum/
> Shared Files: http://ontolog.cim3.net/file/work/OOR/
> Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?OpenOntologyRepository



_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/oor-forum/
Subscribe: mailto:oor-forum-join@xxxxxxxxxxxxxxxx
Config/Unsubscribe: http://ontolog.cim3.net/mailman/listinfo/oor-forum/
Shared Files: http://ontolog.cim3.net/file/work/OOR/
Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?OpenOntologyRepository

--
Kojeware Corporation

_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/oor-forum/  
Subscribe: mailto:oor-forum-join@xxxxxxxxxxxxxxxx 
Config/Unsubscribe: http://ontolog.cim3.net/mailman/listinfo/oor-forum/  
Shared Files: http://ontolog.cim3.net/file/work/OOR/ 
Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?OpenOntologyRepository     (01)