User: Password:
Subscribe / Log in / New account

release early, release often

release early, release often

Posted May 3, 2007 14:02 UTC (Thu) by drag (subscriber, #31333)
In reply to: release early, release often by johoho
Parent article: A tale of two release cycles

Well as they mature you get a wider audiance at the same time that there is less need to actually push forward as hard.

Software tends to go through a life cycle. I think I may of gotten a variation of this from a ESR book...

Baby Stage: 'Stratch your own itch' project. Developer sees a need and develops the basic software. Makes a lot of assumptions, makes a lot of guesses. He doesn't have a lot of information to work on so he is making it up as he goes along.

Childhood: If the project survives it's own birth it will attract new developers. The project is small and nimble with a relatively focused and small code base. People are excited, hype is generated about the possibilities. Lots of amazing work, lots of innovation and new ideas.

Adolescence: The code base is bloated and large now compared to what it used to be. Many original developers are driven away by politics and often are more interested in starting something new and exciting rather then maintaining a bloated code base into the future. Often marred by large amounts of missing functionality and lot of the stuff that works may be worthless to most people. Things the original developer thought was important turns out to not be. Things that were considured to be small details turned out to be big roadblocks. Original code base is stressed out. etc etc.

So here is were most project die or at least go into maintainance mode unable to proceed much further. People go on and take the lessons learned and start new projects (going back to step 1).

If it survives adolecense and survives being rewritten then it will enter maturity, it's golden years. The core code is refined, bug free, reliable. Usually it will be extensible and be able to meet the needs of many different people without having to resort to hacks and headaches.

By that point most people will stop caring about it. It will be mature, boring, and it will 'just work'. Somebody may have a eureka moment and it will have new hype and new development.. but mostly the hype will be focused torwards projects that use this project as a dependency.

If you can imagine some very common projects....

Like, for example:

RCS to CVS to SVN for client-server version control systems.
Then people trying different approaches with Git and Arch.

Going from new --> mature to new --> mature and over again. Each replacement improving and refining their respective approaches. The solutions and advances the CVS developers worked on paved the way for SVN and other newer revision control systems.

Or another big example is the XFree86 to fork.

They took a dying middle-aged project and turned it back to childhood through a fork. Using lessons learned in the past they may pull it off it will skip adolescence and drift happily off into it's golden years. Then new users adn even existing users will stop caring about X at all.. because they will no longer have to. The interesting things will be what people are doing with X.

Lots of projects are following this pattern. Debian/Ubuntu, GCC/EGC, the refining of Gnome. Gnome 1.x vs 2.x. The ABI/API purge of KDE3/QT3 to KDE4/QT4 transition. etc etc.

Of course major software projects may go through many multiple cycles like this.

(Log in to post comments)

Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds