2008/8/7 R.Nagy József <jozsef.rnagy@site.hu>
> Agreed:
> - project needs more, regularly active developers onboard (eg not ppl
> like me 'lately')
> - to achieve this, code needs to simplified, just as said, and the
> process of getting new modules/improvements into <whatever repo> needs
> to be transparent and shortened for anyone (ppl get bored/lose
> motivation quickly)
> - theming and UI must be simplified too, means great improvement from
> users' and less technically (codewise) oriented designers' point of view
>
> Comments:
> - As the number of committing developers grows, the harder it will be
> to keep things secure and _tested_, something that shall not be
> satisfied imo, this -among others- keeps Gallery an outstanding product.
> The need for unit tests itself -and understanding that system first of
> all- scares off most dudes I've talked with. It's gonna be a great
> challenge to keep tests etc in, but make it simple enough.
>
> - "THREE MONTHS" : sounds good, but you can not expect new ppl to take
> on it - and most likely that would not be a good idea anyway-, so it
> has to be done by current developers. After taking a look at the
> current list and size of core and other modules, 3 months is a very
> short time, rewrite is not realistic imho, but refactoring from the
> base would be nice.
Very good points.
@Tests or How simple is simple enough?
- Requiring unit tests is a huge barrier.
- Keeping unit tests around, i.e. designing the application for testability,
requires some abstractions (e.g. GalleryPhpVm) which raise the barrier and
add bumps to the learning curve.
- Accepting but not requiring tests will lead to breakage of existing tests
and a lot of maintenance work for the few that declare to keep the tests up
to date.
- Dropping unit tests is bad in the long term. Even when the core
application is slimmed down, we'll need test automation for QA.
- Drupal, typo3 and other open source PHP projects have started without test
automation and some of them have added or are adding tests right now and are
willing to require tests for all core code submissions.
I think the key is to keep the core code / the official core project
reasonably small.
We don't have to dumb down the code design of the core application. It's
sufficient if we make it a lot simpler than it is now. And there is a lot of
potential to make it simpler without getting rid of useful abstractions and
design patterns.
We can then design the core with proper abstractions, designing for
testability and still provide a reasonably simple code base.
The goal would be that you could do tty much everything with Gallery
without having to modify the code base of the core.
Much more code would live outside of the core application. I guess there
could be a list of officially maintained plugins (not part of the core
project) and 3rd party plugins.
For the core project we'd still require tests, for official and 3rd party
plugins we'd have maintainers that have their own authority on how to ensure
QA, with or without test automation.
There are lessons we can learn from typo3 and other projects in putting
processes into place for code and security reviews of non-core code. End
users could then decide to only use 3rd party plugin releases that have been
audited for quality and security.
And there are lessons to be learned from projects that have started with
usability and simplicity in mind like Zenphoto. You can start too simple (no
internationalization, no plugin system) and then get into problems when you
need to add all the features people are asking for. We learned some of those
lessons with G1 already.
@three months:
I think 3 months is unrealistic to implement a lot of drastic changes.
If you had 2-4 full time engineers you could do it in 1-2 months. If you
have ~3 engineers working on and off 5-15h a week on this project and have
many other things on their mind, then you need a lot more time.
Either way, let's talk about the time frame later. Let's first talk about
things that we'd like to change. Let's come up with UI ideas, features that
should be in there. And then let's talk how the UI and those features should
be backed by an application / framework. And then we can talk about how to
tackle this, incrementally or not.
@what future do we want to have?
Everything that has been said is very true. G2 is too complex, G2 needs a
thriving developer community to survive and making things simpler is they
key to get there.
Say we achieve all that. We release the next generation (NG) version of
Gallery. Gallery-NG is a pleasure to use, it's simpler to hack, easier to
maintain, etc.
Where do you see the project in 2 years?
Despite being such a great product, will there still be a market for
Gallery?
I find myself recommending Flickr, picasaweb and other photo hosting
services to people that just want to share their images and don't have any
technical background. Even with neat auto installers, even an easy to
install web application requires maintenance (upgrades) and it requires more
technical knowledge to create a webhosting account than to create a Flickr
account.
Gallery (1) was once the best and easiest way to share your photos on the
web. That was at a time before there were social networks and photo
sharingwebsites.
Things have changed and the target audience for self hosted web applications
is much smaller today. Is it smaller in absolute numbers? I don't know.
And for people who fer having their own website but don't want to deal
with all the maintenance, there are thin solutions that let you sent your
Flickr / picasaweb photo albums on your own website.
So who is still interested in Gallery? What's the audience we want to target
this simplified Gallery application for?
Your mom? No, she'd be a user of a photo hosting service. Well, unless
you're the maintainer of that service, based on Gallery-NG.
*It's about people who enjoy freedom. Freedom not to be limited by the
design or feature limitations of a photo service. Freedom to post any kind
of photo / video without worrying that the service cancels your account or
deletes your photos without notice.
It's about people who would like to build their own website and may even
have fun doing the occasional upgrades and discovering new features and
improvements.
It's about people who host their own (small?) community website. Integration
features are key in this segment. Scalability as well.
*
The bulk of the market is using social websites and photo sharing services.
It's a niche. But an important niche.
<sidenote>
As a sidenote, I see G2 as a special purpose CMS, or application specific
CMS. It's got most of the infrastructure to be a step away from a really
nice CMS, but it never made that step. It didn't because it's too complex to
attract a larger developer community to thrive a diversification into other
markets.
So this Gallery-NG will probably be farther away from being a CMS. It would
be simpler, even more application specific.
</sidenote>
So, that's what's left of the market after taking social websites and photo
sharing services into account.
What about general purpose content management systems (CMS)?
CMS are growing into Gallery's market as well.
Although we invested quite a lot of effort into designing G2 for
integration, we are very far from doing an excellent job in this regard.
Mostly because integration is too complex. I can take the bulk of the blame
for that, yay!
And Gallery didn't provide the more modern means to integrate (RSS, RESTful
APIs, etc.).
When talking about integration, there are basically two markets:
- Integration into mostly static websites, mostly for sentation
(displaying an album, or a slideshow on some website).
- Tight integration with a CMS assuming responsibilities for all matters
related to photo (or even media) management.
My efforts have been mostly targeting the latter market. Mostly, we made
tight integration possible, but still too complex.
I'd define success as most PHP CMS using Gallery for photo (or even media)
management and sentation. Everything else leads to too much duplication
and segmentation of effort. If the bulk of the talent pool could innovate
based on the same code base, everyone would get a lot more out their
investment.
That's not where we are. CMS are implementing their own image / media
management solutions.
So let's look into the future again. 2 years from now, CMS like drupal are
still growing their community at an imssive rate and they'll come with
excellent image management features and all the other goodness that their
CMS community provides (mature core project, tons and tons of docs and
books, groups working on usability, security, scalability, you name it).
They'd have learned their lessons as well and provide application specific
installation profiles (similar to Eclipse, that's where Drupal is headed)
and thus provide an easy to install Gallery application without having to
configure all the CMS options / plugins to get there.
>From the niche that is left after taking photo hosting services into
account, what would be left after taking such CMS solutions into account as
well?
Remember what's left after taking services into account (see above).
Integration is key for most of the remaining users.
It's going to be hard to compete for this shrinking market. It's a fight at
two fronts.
Our declared goal is to provide a "best of breed" product and to seamlessly
integrate with applications from other areas.
Either we'd need to give up on tight integration and focus on providing the
RSS, REST APIs for integration with small websites, social networking
websites etc.
And we'd lose another piece of the market.
Or we'd need to keep the gap between our solution and what general purpose
CMS can provide reasonably large, else there's not much incentive to jump
through the hoops required to maintain and integrate multiple applications.
And we'd need to focus even more on tight integration (this is not about
RSS, REST, more about session, user management, search integration, content
management features (e.g. providing some album / item to the CMS via an
API), template systems, etc.).
Which might be at odds with our goal of simplifying things and which
certainly requires quite some development effort.
Conclusion:
Gallery as a project might not grow much even though we might be doing
everything right. That's because the niche in which we operate is a
shrinking piece of the market, fighting service oriented solutions on one
front and CMS solutions on the other.
I see a lot of reasons to believe that Gallery will be more fun to work on
in the future that we all envision.
And that might be enough reason to make these things happen. No matter
whether Gallery's niche is shrinking, no matter whether there's much
potential to grow Gallery's market share.
So, what future do we want to have?
Do you want to spend time working in this niche? What's your definition of
this niche market, who are the customers you'd like to have?
As a developer / contributor, you have to find an answer to that question
yourself.
As for integration matters, I think more discussion is needed. We'll know
more once we talk more concrete about the design of Gallery-NG.
- Andy
>
> Who is with you in making G2 an even better, more widely used product?
> Of course I am (as much as possible).
> --
> Joe
>
>
> Idézet (Bharat Mediratta <bharat@menalto.com>):
>
> > 2.3 is just about out the door so it's time for us to start thinking
> > about what happens next. At the Gallery meetup this year, we had a
> > discussion about the state of the project, what we're doing well, what
> > we're doing poorly and some concrete steps that we can take to improve
> > things.
> >
> > The project as a whole is doing well. We have lots of users, lots of
> > attention and are still the leading project in our field. We may not
> > have a huge developer community, but those that we have are talented
> > and passionate. We're continuing to make forward progress, make users
> > happy, and put out a high quality product. In other words, the
> > future of this particular market is in our hands to drive or fumble.
> >
> > Things are not all rosy, though. We have problems that are eventually
> > going to lead to the slow demise of the project. These are things
> > that we can, and must fix in order to make this project the very best
> > that it can be. There are many issues, but they all culminate in one
> > major problem which is that we do not have enough people working on
> > the project. My main theory for this is because we have a product
> > that is too complex for the average casual hacker to come up to speed
> > on it. The developers that we have are highly skilled and well
> > versed, but the pool of talent that can produce such developers is
> > small and therefore we are always going to have a difficult time
> > growing them. Without more core developers, we will have a difficult
> > time really getting the critical mass we need to have a thriving
> > community. Without a thriving community, we will have a hard time
> > doing things like fixing the user interface, developing a set of
> > secondary support products (like Gallery Remote), taking advantage of
> > emerging technologies (WebDAV, OpenID), etc.
> >
> > My theory for why we don't have enough developers is that Gallery 2 is
> > far too complex a product. I take the bulk of the responsibility for
> > this. Gallery 1 grew organically from specific needs and we had a
> > simple and pragmatic focus on adding features. It didn't always grow
> > in the right directions, but it was relatively simple to pick up,
> > understand and hack. But then I indulged myself when I created
> > Gallery 2 and blundered into making a classic mistake: the second
> > system effect[1]. Gallery 2 was designed to solve all problems well,
> > but in its ambition it really only solves most problems poorly.
> > Harsh? Perhaps. But if anybody has the right to throw the first
> > stone, I think it's me.
> >
> > We discussed some plans for fixing this problem and they all boil down
> > to this: SIMPLIFY.
> >
> > Let's get together and take a hard look at the product from a user
> > perspective. Make a list of all the features that users really care
> > about and then build the simplest implementation that meets them all.
> > Use -existing PHP5 frameworks wherever possible. Take advantage of
> > what PHP5 has to offer. *Ignore and delete* rarely used features.
> > Focus on the 80% of our users and build a product for them. Don't
> > worry about the screaming 20% who wants nifty new features, they are a
> > distraction. We should not be building a product that runs on 5
> > different databases and supports webdav, unless there's overwhelming
> > evidence of widesad use. Start at the top down by *building the
> > user interface FIRST* and then build the application to support it.
> > Make it dead simple to theme. Don't sacrifice security, but don't
> > generalize until we absolutely need it. Support migrating the core
> > data from Gallery 2.3, but be willing to throw out extra crap unless
> > it's obvious that we need it. Get rid of our complex permissions
> > system. Use a simple database structure! Make sure that it's easy to
> > embed in other apps using the hot new web 2.0 integration forms (RSS,
> > REST, JSON, etc). This is a very abbreviated list, we should have a
> > much longer discussion around our redesign constraints, but I'm throwing
> > these out there to give you an idea of how far I want to go.
> >
> > We can refactor the existing product towards the goal, or we can do a
> > rewrite, but either way after we emerge from the design phase we will
> > implement the entire thing in THREE MONTHS. If we're not writing a
> > crapload of extra code it won't take us that long.
> >
> > So that's my plan. Who's with me?
> >
> > -Bharat
> >
> > [1]: http://en.wikipedia.org/wiki/Second-system_effect
> >
> > -------------------------------------------------------------------------
> > This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> > Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> > Grand prize is a trip for two to an Open Source event anywhere in the
> world
> > http://moblin-contest.org/redirect.php?banner_id=100&url=/
> > __[ g a l l e r y - d e v e l ]_________________________
> >
> > [ list info/archive --> http://gallery.sf.net/lists.php ]
> > [ gallery info/FAQ/download --> http://gallery.sf.net ]
> >
>
>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> __[ g a l l e r y - d e v e l ]_________________________
>
> [ list info/archive --> http://gallery.sf.net/lists.php ]
> [ gallery info/FAQ/download --> http://gallery.sf.net ]
>
>
|
