Hi Pierpaolo,

Agreed, that is my thinking too, like wordpress.org + wordpress.com, one 
Open Source portal and one commercial portal.  The only thing that has 
happened is that there is link to documen.to in the support section of 
mayan-edms.com.  Maybe another link or two in the future but I want to keep 
them separated, with their own branding and distinctive visual themes.  

On Friday, August 31, 2012 3:05:37 AM UTC-4, Pierpaolo Baldan wrote:
>
> Ciao Roberto
> don't mix Docume.to with Mayam (Documento should become the main stone 
> for branding and the professional support).
> Apache is my favorite one.
> Using the commercial version when you sale it's as an appliance, for a 
> question of providing warranties about all .
> Pierpaolo
>  
> 2012/8/31 Roberto Rosario <[email protected] <javascript:>>
>
>> Thanks to everybody who shared their opinions I appreciate it a lot.  The 
>> consensus on almost every issue was very consistent or close to 
>> consistent.
>>
>> *- Should Mayan EDMS be licensed under another Open Source license (BSD, 
>> MIT, Apache, other)?  A non Free license?*
>> No.  General consensus is that it should remain under the GPL with some 
>> of you suggesting a closer look to the Apache license. 
>>
>> *- Should it remain Free Software or move to a full commercial product.*
>> Remain Free Software was unanimous, but there were quite a few suggestion 
>> for even greater commercialization strategies compatible with keeping the 
>> project a FOSS project.
>>
>> *- Should a new specific license be crafted for it (ie: Mayan EDMS 
>> Shared Source License or something like that)*
>> No.  The majority of the reasoning was the work involved in crafting a 
>> new license and the confusion it may cause with end users was not worth the 
>> effort.
>>
>> *- Should the development branch remain open, closed, or shared on a 
>> case by case basis?*
>> Consensus was that the read access should be open, but a process of 
>> validation should be in place for the inclusion of patches, others 
>> mentioned requiring a signed contributors agreement to protect the project 
>> from code that is licensed or patented.  Code contamination has been 
>> a preoccupation in the back of mind for a while and I'm glad it is a topic 
>> other find important too.  Sadly any process that may ultimately is 
>> implemented could/would lower developer participation.  Let see how this 
>> one unfolds.
>>
>> *- Should the release strategy remain the same or should there be 
>> a deferred model of a commercial release and have that same version become 
>> the latest Free Open Source version a period after that (6 month a a year?) 
>> to benefit both commercial and non-commercial users? 
>>  Another completely different release strategy?*
>> A more strict 6 month release schedule was the most common answer. 
>>  A suggestion of interest is that this would be an area where developers 
>> could do unofficial releases by merging development code and release their 
>> own 'testing' versions of Mayan while the official development 
>> version stabilizes.  It would give developers a chance to showcase their 
>> abilities, practice with new code and at the same time end users could 
>> benefit by seeing what changes the next version will include.  The project 
>> would benefit by having development code tested even before it gets 
>> released.
>> *
>> *
>> *- Should there continue to be only one version of the Source Code or 
>> should there be a commercial and a community version?*
>> This was the only issue where opinions were most varied.  Suggestions can 
>> be grouped in 4 groups:
>>
>>    1. Single version
>>    2. Dual version (FOSS and commercial) 
>>    3. 3 version model: FOSS, commercial and enterprise
>>    4. 3 version model: FOSS, commercial and mini.  Mini would be a 
>>    version of Mayan with a very small and simple feature set, meant for 
>> people 
>>    not wanting a full fledged version of Mayan because have never used a 
>>    DMS or just want a web based replacement for *Windows Explorer* <= 
>>    actual words :) 
>>
>> *- Should there be a completely different release strategy?*
>> No
>>
>> *- Is the current release cycle adequate?  Or Too slow?  Too fast?*
>> It is adequate
>>
>>  *- Should a non profit foundation be established and all or some 
>> control be transferred to it?  Should copyrights be transferred too?*
>> Opinions were divided in two groups:
>>
>>    1. No 
>>    2. Yes, but in the future w/ copyright transfer
>>
>>
>> *- Is the software/project transparent enough or too much?*
>> No issues with current transparency
>>
>>
>> *- Is the new licensing plan proposed (GPL, Redistribution, Commercial 
>> and Developer) adequate, too complicated or too limited?*
>>
>> """
>>
>>    - ** GPL ** – You can install *Mayan EDMS* as is, but can sell your 
>>    services for *Mayan EDMS*, you must provide the source code or 
>>    directions where to get the source code to your clients, modifications to 
>>    the source code must be made public. 
>>    - ** Redistribution ** - You can sell *Mayan EDMS* as well as your 
>>    services, you can modify *Mayan EDMS* adding new features or changing 
>>    the name and you can keep your changes closed. 
>>    - ** Commercial ** – Same as *GPL* but includes email and telephone 
>>    support for a number of hours per month. 
>>    - ** Developer ** – Allows you to use *Mayan EDMS* to create a new 
>>    product using all or parts of the source code and allows you to sell your 
>>    new product independently. 
>>    - """
>>
>>
>> Majority found it adequate with 2 additional suggestions:
>>
>>    1. Hardware license - You can include Mayan EDMS on embedded hardware 
>>    as part of a custom scanning/printing hardware solution.  Target 
>>    sector: Printing presses, office equipment vendors.  I though that under 
>>    the GPL or Redistribution license this would be possible so I asked for 
>>    additional clarification. 
>>    2. Resale license - Didn't quite understood this suggestion either 
>>    and am waiting for more information.
>>
>>  
>> *Any other topic regarding but not limited to code hosting (github, 
>> etc), the current website hosting, website design or anything else is also 
>> most welcomed.*
>>
>>    - Move to other hosting
>>    - Web site redesign with commenting and feed subscription options was 
>>    the most common answer. 
>>    - Other topics presented:
>>       - Merge of my startup website www.documen.to with Mayan's website 
>>       into a single website.  I don't completely agree with this one, but 
>> will 
>>       try to connect them more and see how it goes. 
>>       - Mayan EDMS swag.  Cool :)
>>       - Mayan EDMS mascot.  Argument is that a mascot is more versatile 
>>       in terms of promotion and marketing than a logo. 
>>       - That some of Mayan EDMS paradigms or solutions should be 
>>       patented, such as the way it does indexing which is unique and to 
>> protect 
>>       it before it is copied and appropriated by the commercial products.  I 
>> have 
>>       a personal anti-patent view and don't completely agree with the idea 
>> of 
>>       patenting features and the counter argument was that it is to protect 
>> Mayan 
>>       itself in the event a commercial product appropriates the ideas and 
>> tries 
>>       to sue to remove Mayan from the DMS market.  The situation exposed in 
>> the 
>>       counter argument is interesting and I definitely need to learn more 
>> about 
>>       the legalese of patent protection, prior art and such with regards to 
>> FOSS. 
>>       - Some issues with the logo and Mayan's branding and its use on 
>>       custom built hardware was brought up. 
>>       - An app or plug in market where developers could use to make 
>>       money without having to work with the entire codebase.  Apps could be 
>>       downloaded and installed by hand or from the program itself like 
>> Wordpress 
>>       does with plugins.  I like this idea a lot, I would certainly love to 
>> see 
>>       an ecosystem of plugins for Mayan in the future and will do my best to 
>>       start moving the code to be even more modular to make this happen. 
>>       - More technical documentation.
>>       - Courses, training and professional Mayan certifications.  This 
>>       one is also interesting. 
>>    
>>
>> Thanks to everybody who voiced their opinions, if you still haven't, 
>> please do I would love to hear your ideas and opinions no matter how 
>> different they are from what has been exposed so far.
>>
>> --Roberto
>>
>>
>> On Thursday, August 30, 2012 1:23:18 AM UTC-4, Roberto Rosario wrote:
>>>
>>> All that has happened in the past 60 hours or so including the results 
>>> have show that Mayan EDMS the code, and Mayan EDMS the project, have broken 
>>> through any initial expectations of growth, market penetration, acceptance 
>>> or any idea I or anyone else may have had from the day it was started or 
>>> the day it was released one and a half years ago.  I also think this is an 
>>> important pivotal point and the good time to make changes if there is the 
>>> need for them to ensure the continued growth and future of the project.
>>>
>>> I value everyone's opinion and take them into account and the people in 
>>> this mailing list are the oldest supporters of the project so your opinions 
>>> are specially important and helpful during this process as have been since 
>>> the beginning of the project itself.
>>>
>>> I would like everyone to chime in if they can on the following topics 
>>> (or any other you want to bring out):
>>>
>>> - Should Mayan EDMS be licensed under another Open Source license (BSD, 
>>> MIT, Apache, other)?  A non Free license?
>>> - Should it remain Free Software or move to a full commercial product.
>>> - Should a new specific license be crafted for it (ie: Mayan EDMS Shared 
>>> Source License or something like that)
>>> - Should the development branch remain open, closed, or shared on a case 
>>> by case basis?
>>> - Should the release strategy remain the same or should there be 
>>> a deferred model of a commercial release and have that same version become 
>>> the latest Free Open Source version a period after that (6 month a a year?) 
>>> to benefit both commercial and non-commercial users? 
>>>  Another completely different release strategy?
>>> - Should there continue to be only one version of the Source Code or 
>>> should there be a commercial and a community version?
>>> - Should there be a completely different release strategy?
>>> - Is the current release cycle adequate?  Or Too slow?  Too fast?
>>> - Should a non profit foundation be established and all or some control 
>>> be transferred to it?  Should copyrights be transferred too?
>>> - Is the software/project transparent enough or too much?
>>> - Is the new licensing plan proposed (GPL, Redistribution, Commercial 
>>> and Developer) adequate, too complicated or too limited?
>>>
>>> """
>>>
>>>    - ** GPL ** – You can install *Mayan EDMS* as is, but can sell your 
>>>    services for *Mayan EDMS*, you must provide the source code or 
>>>    directions where to get the source code to your clients, modifications 
>>> to 
>>>    the source code must be made public. 
>>>    - ** Redistribution ** - You can sell *Mayan EDMS* as well as your 
>>>    services, you can modify *Mayan EDMS* adding new features or 
>>>    changing the name and you can keep your changes closed. 
>>>    - ** Commercial ** – Same as *GPL* but includes email and telephone 
>>>    support for a number of hours per month. 
>>>    - ** Developer ** – Allows you to use *Mayan EDMS* to create a new 
>>>    product using all or parts of the source code and allows you to sell 
>>> your 
>>>    new product independently. 
>>>    - """
>>>
>>> Any other topic regarding but not limited to code hosting (github, etc), 
>>> the current website hosting, website design or anything else is also most 
>>> welcomed.
>>>
>>> Feel free to post or to continue emailing me in private as most have 
>>> done, any method is perfectly fine.  Thank you very much,
>>>
>>> --Robert
>>>
>>>  -- 
>>  
>>  
>>  
>>
>
>

-- 



Reply via email to