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
>
>
--
