2008/8/7 R.Nagy József <jozsef.rnagy@...> > 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 pretty 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 prefer having their own website but don't want to deal with all the maintenance, there are thin solutions that let you present 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 presentation (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 presentation. 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 impressive 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@...>): > > > 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 pre-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 widespread 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 ] > >