aC 1.0 release strategy
Submitted by Ahmed on Tue, 08/21/2007 - 23:16.
Has anyone gotten any information regarding how aC 1.0 is going to be opensource to any degree?
This can help determine our own marketing efforts.
Has anyone gotten any information regarding how aC 1.0 is going to be opensource to any degree?
This can help determine our own marketing efforts.
http://www.activecollab.com/blog/37/status-update-followup/
IMHO one of our success factors is to be as open as possible, meaning that the app should be (and stay) OpenSource and we should invite everyone to participate.
In both areas aC failed and still fails - the license change (and the way it was communicated) disappointed a lot of people and the closed development cycle brings a lot of announcements but no delivered software. We can do better in both points.
IMHO, we can do better, but this is the priority to make that happen:
1) Organize developers and testers - right now we don't have a real development team - and that's my fault. I plan to concentrate on this after version 0.8 is released.
2) ProjectPier will always be open source, no questions, as long as I'm involved.
I agree and we will have to attract people with different capabilities. After 0.8 we should "formalize" some responsibilities, set up a project structure for the next release, and produce more infos about how to contribute - this could be one of the first tasks of the sub project leads/coordinators.
Right now there is some of us who will produce some stuff (and often too late *shameonme*) and we don't meet the announced dates. This is very bad. After 0.8 we should discuss release cycles and goals for these in the different pp fields (development, marketing/communication, documentation, community building, standards, and so on).
Right now this is a great possibility for new people to join a brand new project and produce a first-class project management tool. So if you want to get your feet wet - please get in contact with us :-)
Roland
PS: I think it has consensus that PP should always be OpenSource and I will support you in that aspect.
I think the key is a PLAN. What is more important, IMHO, than when.
Get what right, and keep each releas's goals small (one to three changes) and the project will go well. Aim to high, and feature creep will kill it.