This is the mail archive of the ecos-devel@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Is the eCos Open Source development model at risk?


I don't entirely agree with your assessment.  I do agree that some
gatekeeper mechanism is needed to keep the eCos sources in a high quality
state, but I think the current mechanism is starting to show its
deficiencies.  I base this on what I think are the some of the most
important reasons for an Open Source development model:

1. The eCos community benefits when the users contribute bug fixes,
improvements, enhanced features, etc. back to the source respository.
2. Having these contributions in the source repository increases the
probability that they will be used and other users will help improve them.

When you post your contributions to the mailing list, after a few months
they are effectively lost to the rest of the community, since it takes a
reasonable amount of effort search the mailing list to find if any
particular patch is just what the user wants.  The eCos community has lost
the benefits of your contribution.  Second, if no one is using your
contribution, you lose the benefit of other users improving your
contribution.  And the situation will get worse, especially if the
popularity of eCos increases and we get more user contributions.

I also disagree with the notion that to get better responsiveness, we
should enter into a service contract with the eCos maintainers.  In the
Open Source model, the respository is community property and it's up to the
community to maintain it and improve it.  Currently the select group of
people who have write access to the CVS tree act like a QA team for the
rest of us.  If they don't have the time to be responsive, we as a
community have to help them out or the community has to development a
different gatekeeper mechanism to improve responsiveness.

The only thing I can suggest at this time, is how do other successful Open
Source projects handle this problem?

Michael Checky




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]