@sharetest
Its really difficult to predict dates things will be completed by because of the complex, co-dependent relationships between all the plugin’s components. The build process is more like painting a picture than building a skyscraper.
We’re working very hard to get the plugin working as quickly as possible. Looks like we’ll probably have an alpha release for Q2, 2012.
Regarding deadlines and such, we covered that in an earlier post:
There seems to be some disappointment regarding the amount of time we’ve spent coding BP-Media versus what the plugin does when you run it on your server. That’s okay. It was planned for, and expected.
So let’s talk about deliverables, dependencies, parametric design, management overhead, and project scope …which are the engineering terms for what many of you are complaining about.
Say you want to fry an egg for your mom. Everybody knows how to fry an egg. You just put a frying pan on the stove, throw in an egg, cook it till its done, and serve it to your mom.
The “deliverable” is the fried egg. The “dependencies” are the frying pan, which is needed to cook the egg, and the stove, which is needed to heat the frying pan.
People frying eggs today have access to the vast amount of experience gained from frying millions of eggs in the past, and can use that experience to estimate how changing parameters will affect the deliverables. How long to cook two eggs instead of one? About the same amount of time. How long to cook an egg really hard? About 50% longer than usual. Frying an egg is a “parametric” problem.
Furthermore, if any dependency in the chain is missing “I don’t have a frying pan to cook the egg”, it can easily be solved by driving to the nearest store and buying a frying pan.
So even starting with no stove, no frying pan, and maybe even no kitchen, I can give you a reasonably accurate time and cost estimate for practically any combination of egg-frying you could possibly think of.
When people talk about “how easy it is to write software” and “huge websites being built in a weekend”, this is the type of design they’re talking about (often without realizing it).
And then there’s the Apple iPod.
All things considered, using an iPod is about as complicated as frying an egg. It also has a dramatically smaller range of inputs (about 20 file types) and only two outputs (audio and video).
There are two main reasons why the iPod took millions of dollars and years of effort to create, despite having the overall UI complexity of a kitchen stove:
a) It has an enormous dependency chain. There are probably 300 different things …from the USB connection to the host computer, to the lithium-polymer battery, to the headphone wires… that *all* have to work before audio files put into the iPod come out as audio in the headphones.
b) It was effectively the first of its kind. While there were a few other primitive MP3 players on the market at the time, Apple had to invent the “essence” of what makes an iPod an iPod, and they had to build huge parts of the dependency chain from scratch.
Its hard to believe the iPod’s been around for over ten years now. Concepts pioneered in the iPod are now taken for granted and used everywhere.
Building BP-Media is a lot more like designing an iPod than frying an egg.
Although there’s tons of open-source software out there that we’ve been able to use to avoid having to write a lot of code, we’ve still had to write huge dependency trees from scratch (like our database class) and design completely new paradigms (like our Page, Album, Media, and Network modules). This work is ongoing and makes it very difficult to give accurate timeline estimates.
In a “typical” software development operation, a significant portion of the development team’s time would be spent building “mock-ups” that would make the plugin appear to work in the user’s browser but wouldn’t actually do anything on the server. These “mock-ups” would be used to demo the plugin to the marketing team and executives, and would then be discarded. This is called “management overhead”.
We’ve chosen to focus our development resources on building-out the dependency chain instead of producing “mock-ups” because we think its a better use of our time. We do realize this has created the appearance of little progress being made despite enormous amounts of code being written.
Re: group albums
No, we’re not releasing anything involving group albums in the next two months. Group albums are a very, very complicated thing to get right.
For example:
1) “What happens when a user adds an item from an album that they own which is set as ‘visible only to friends’ to a group album that is set as “public”.
2) “Should groups be able to have multiple albums?”
3) “Should anyone in the group be able to add items to a group’s albums, or just the admin?”
4) “Should group members be able to delete other group member’s items from the group album?”
5) “When somebody comments on an item in a group album, how should it integrate with the activity stream?”
Download the latest nightly build and try it out…
http://code.google.com/p/buddypress-media/downloads/list
Follow our Twitter feed:
http://twitter.com/bpm_dev
^F^