Something that might help to move in this direction is conducting an
informal survey of what features (including bug fixes and documentation)
people would like to see, and a list of what expertise that people are
willing to lend to the project, AND an idea of how much time they could
realistically dedicate to these efforts over the coarse of a given year.
At that point you have some idea of the resources you have to throw at
the problem. I hope that things have changed over the last 5 years, but
I still expect that there are only 4 to 6 serious developers (spending
more than 10 hrs/month every month for a year or more). If that is
still the case then you need to find out what they need to refocus on
your priority list and maybe spend more time. If you find some fresh
blood, then treat them kindly.
Well, that's my 2c. I'm off to a party.
EBo --
On Sat, 22 Oct 2011 11:42:20 -0700, Kirk Wallace wrote:
> On Sat, 2011-10-22 at 07:00 +0000, Chris Morley wrote:
> ... snip
>
>> To some it up it seems EMC has gotten pretty far without a lot of
>> planning
>> imagine where it could go with a rough road map !
>>
>> Chris M
> ... snip
>
> You raise a lot of good points Chris. I don't see that technically
> any
> of these issues are all that hard to fix. It's just a matter of each
> of
> us who cares to turn up the wick a little, but also in a way that is
> mindful of the state of the whole.
>
> It may be that EMC2 is at a point like a start-up company where a few
> clever engineers come up with a product, then find the demand for the
> product outgrows their ability to manage it. It seems to me,
> companies
> where the engineers try to continue to manage the growth the old way,
> don't grow, or more likely fail. The only companies that grow find
> new
> management that know nothing about the product and a lot about
> management.
>
> I find that engineers are particularly management averse, especially
> when they don't get paid, so it may be best to adjust our
> expectations.
> In EMC2's case, the only way it can fail is if it losses its
> repository,
> so I think the current situation could go on for a long time. People
> could continue to drop in and out as they please. Those that want
> change
> may need to drive it alone and may need to step on toes along the
> way,
> or learn to compile source and keep their own version locally.
>
> To me, there seem to be hints that at least a few proprietary
> versions
> are living separate lives with the proprietors keeping their work to
> themselves. This may be a good thing, if these versions push EMC2
> into
> new areas, in turn creating more general interest and helping to
> justify
> keeping the current repository going. On the other hand, I could see
> someone patenting a new feature and preventing its use in the open
> version. The GPL license may prevent this, I don't know.
>
> The coffee is waring off, so my thoughts on the short term, and the
> way
> I try to look at EMC2; it is what it is, if I need something, I ask
> for
> help. If I don't get help, I try to figure out if it is worth it to
> figure it out on my own. If I do figure it out, I try to pay it
> forward.
> Could EMC2 be better? Yes. Will it change? Probably not, and overall,
> would not be a disaster. Would I mind if someone tried to make it
> better? Not at all, and I may even try to help, if I can.
------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
