View Full Version : Proposal: Garage badging
Discussion at this thread (http://talk.maemo.org/showthread.php?p=311858#post311858) got me thinking-- maybe we need some sort of incentive for developers to maintain projects in Garage or Other. This can range from punitive ("Sorry, this app was not Garaged managed so it cannot be installed" to suggestive ("Warning: app was not Garaged managed. Continue anyway?") to laudatory ("This app was proudly Garaged! managed").
What are the thoughts on this, and does Garage/Maemo [or Other] support the sort of technology needed? I'm thinking it's almost a must...
EDIT: note that I do not mean to exclude any other official content repository or management mechanism.
EDIT 2: guess Edit 1 was not enough... sigh.
You seem to think that all programs should be hosted in Garage. Why?
There is already http://wiki.maemo.or/Extras_repository_process_definition which is for improving quality of packages is Extras.
Ok, don't get too fired up-- it was a general idea and I just used Garage as the main example-- but that would not exclude Extras. I'm looking more for feedback on the concept, not axle-wrapping over details.
Eh.. I see what you're trying to do here, but I don't think that's the way to go about it.
Instead of giving the developer incentive to continue working on his projects, it looks like it punishes the user for wanting to install something outside of Garage. Yet another dialog box when I'm installing something? ;)
Perhaps added Karma for a project for each major release/update? (I say "major" because I don't want people spamming updates for Karma.)
GeneralAntilles
2009-08-15, 00:54
Discussion at this thread (http://talk.maemo.org/showthread.php?p=311858#post311858) got me thinking-- we need some sort of incentive for developers to maintain projects in Garage.
Why? Garage is appropriate for certain projects, but certainly not for all of them (if even most of them).
Why? Garage is appropriate for certain projects, but certainly not for all of them (if even most of them).
I get the feeling one of my posts and an edit are invisible... :p
Eh.. I see what you're trying to do here, but I don't think that's the way to go about it.
Instead of giving the developer incentive to continue working on his projects, it looks like it punishes the user for wanting to install something outside of Garage. Yet another dialog box when I'm installing something? ;)
Perhaps added Karma for a project for each major release/update? (I say "major" because I don't want people spamming updates for Karma.)
Thanks for seeing. ;)
Just looking for incentive to maintain projects in formal environments (not just Garage!!!!) where, if the original developer drops it, someone else can easily pick it up.
If this is a disincentive, then I daresay I don't want that person's product.
Anyway, I'm not religious about my suggestions-- just looking for workable solutions to what I see as a major stumbling block. I do find it disappointing that 2 responses so far are focusing on trees when I'm talking forest.
sjgadsby
2009-08-15, 01:49
Perhaps added Karma for a project for each major release/update? (I say "major" because I don't want people spamming updates for Karma.)
Just looking for incentive to maintain projects in formal environments (not just Garage!!!!) where, if the original developer drops it, someone else can easily pick it up.
Do you feel "Task:Karma for applications" (http://wiki.maemo.org/Task:Karma_for_applications), particularly "Frequency of updates" and "Number of contributors in Garage", is moving maemo.org in a direction approximating that which you're wanting? If so, how do you feel the task could be improved further? If not, how is the task failing to strive for the goals you're seeing?
I think Karma is a great idea for this purpose... I was just wondering if something stronger might be feasible and useful, at least for perhaps a "premier" tier of apps. I may be just nuts based on responses though. If so, ignore me, I'll shut up eventually. :D
sjgadsby
2009-08-15, 02:24
I think Karma is a great idea for this purpose... I was just wondering if something stronger might be feasible and useful, at least for perhaps a "premier" tier of apps. I may be just nuts based on responses though. If so, ignore me, I'll shut up eventually.
I didn't intend to suggest to keep quiet or go away. I simply pointed to an in-progress effort that seemed related to your stated goals, an effort of which you may not have been aware.
So, exploring further, you mentioned "badging". Would a collection of small icons, appearing on application pages within Download and, perhaps eventually, within Application Manager, help? I'm visualizing small, simple, representative images, along the lines of those used to indicate Creative Commons protections/freedoms.
So, off the top of my head:
free-as-in-beer/shareware/commercial trial/commercial
non-subscription/free-as-in-beer subscription/commercial subscription
OSI approved license/public domain/closed
developed in repository readable by public/not
Warmer or colder?
Warmer (and I was not meaning to imply anything about you in my comments).
I see the best implementation of any sort of certification as orienting around App Manager. Something to inform users: "hey, THIS app is being well-managed so you have less to fear over possible abandonment". Such info should be available when previewing app info. Apps following this process could enjoy other benefits as well, such as prime rotation appearances in Downloads. Just a thought.
I'm not trying to step on any toes here or suggest draconian measures. Bottom line: how do we assure users that apps will likely be maintained, and how do we TRULY encourage coders to indulge? And if my questions are moot or foolish, hey, I can accept that.
Bottom line: how do we assure users that apps will likely be maintained
That's never guaranteed, but IMHO the best indication would be source code being available under a Free Software/Open Source licence.
Another effort which helps here is the push to get everything in Extras. The benefits for the user:
No faffing with "catalogues" or "repositories", they just see lots of great quality software available to install.
The benefits for the developer:
A pooling of testers through extras-testing who will hunt down and report bugs.
A large pool of users available to them.
The benefits to the community:
Packages get into Extras by being compiled by the auto-builder. This means source is available should the developer stop developing.
That's never guaranteed, but IMHO the best indication would be source code being available under a Free Software/Open Source licence.
The other advantage of a Garage project is that the source code should remain available, even after a dev has moved on and perhaps removed their own public repo from wherever it was hosted. I think this continuity would be a good reason to ensure that projects do have a Garage project associated with them, even if the Garage SCM isn't used for day-to-day development and rather hosts snapshots.
That's never guaranteed, but IMHO the best indication would be source code being available under a Free Software/Open Source licence.
I was hoping this discussion could avoid the obvious folly of absolutes...
I'm aware there is no such thing as 100% guaranteed... I'm looking for a reasonable level of assurance-- ie, more than is apparent now.
I am really frustrated though by how this is going so far, so maybe I really should shut up. I can see by thanks and responses that either I'm not communicating well or what I'm trying to discuss is seen as a bad idea from the outset...
The other advantage of a Garage project is that the source code should remain available, even after a dev has moved on and perhaps removed their own public repo from wherever it was hosted. I think this continuity would be a good reason to ensure that projects do have a Garage project associated with them, even if the Garage SCM isn't used for day-to-day development and rather hosts snapshots.
You seem to be the only one understanding what I was aiming for. Maybe we're both crazy? :D
It would also be helpful if some of the changes and hacks made weren't just kept on the developer's site or just in Garage, but an attempt made to push that code upstream - as Nokia themselves has been doing. Also, by pushing that code upstream, we might be able to get upstream developers interested in developing for Maemo specifically, which has happened a few times already.
The other advantage of a Garage project is that the source code should remain available, even after a dev has moved on and perhaps removed their own public repo from wherever it was hosted.
Certainly, both licence and code availability are important (see for example the ruby-hildon situation).
I wouldn't go as far as mandating (or even just offering incentives for) use of Garage as there are lots of valid reasons why developers may not want to use it. Besides, publishing in extras also ensures source code availability so isn't the push for extras enough to cover the disappearing developer case?
Certainly, both licence and code availability are important (see for example the ruby-hildon situation).
I wouldn't go as far as mandating (or even just offering incentives for) use of Garage as there are lots of valid reasons why developers may not want to use it. Besides, publishing in extras also ensures source code availability so isn't the push for extras enough to cover the disappearing developer case?
I've been trying to move past that word Garage, as it has turned out to be a totally unnecessary stumbling block, but I admit the original error was mine in the first place.
Can we agree that SOME sort of public content management has distinct advantages for the community and especially end-users, over private content management? Doesn't the latter work against the very concept of FOSS?
I've been trying to move past that word Garage, as it has turned out to be a totally unnecessary stumbling block
Sure :-)
Can we agree that SOME sort of public content management has distinct advantages for the community and especially end-users, over private content management?
Agreed, and since we have extras in place, and it comes with a very good incentive for developers (repository enabled by default) from Fremantle onwards, is anything more needed?
Can we agree that SOME sort of public content management has distinct advantages for the community and especially end-users, over private content management? Doesn't the latter work against the very concept of FOSS?
Yes, you are absolutely right. But where's the problem? I don't know any open source projects for Maemo where source code isn't easily available from some public place.
Yes, you are absolutely right. But where's the problem? I don't know any open source projects for Maemo where source code isn't easily available from some public place.
I can't name any offhand, either, but others have reported abandoned projects with no access to the latest source...
KristianW
2009-08-15, 21:42
Texrat certainly has made a valid point.
So DO let's start thinking about it,
and see if any ideas for further improvements CAN be found.
As I understand Texrat, he includes projects started by amateurs and budding pro's,
so here is one small comment :
Among many reasons why projects are abandoned,
or why abandoned projects are not picked up,
one could be that the code is too sparesly commented, or not clearly enough structured.
And commenting code well encourages good coding.
( One of the most popular word processors in CP/M - MS-DOS times was coded after the manual was written, according to grapewine.)
So, can that be encouraged ?
Can beta testers be encouraged to look at (parts of) the source, and then somehow give karma ?
Can karma for easily understood code somehow make life easier for the project ?
One post pointed in a similar direction by suggesting karma for good management.
Thanks Kristian.
And many already know it, but I have to make it clear that 95% of my development and management background is Windows-based. I have never coded much less released a Linux app of any kind so my portions of any dialog along these lines is shaped by the comments/complaints of others. Given that, it's highly likely I've commited some errors of understanding that have gotten in the way of this topic.
What would help me is a basic process map of the suggested maemo development/release /install/support process. Does such a thing exist? If not, can one be worked up? I would gladly put it into Visio if I had a partner who could get me up to speed...
EDIT: thanks to Jaffa I found this-- http://wiki.maemo.org/Extras_repository_process_definition
It's a start!
KristianW
2009-08-16, 00:15
Texrat ,
( I'm not a programmer, not even small scale.)
Agreed, it's a start.
But very little is said
about encouraging programmers to make easily supportable code ,
( which also makes coding easier as the project grows,)
or about easing the unexpected hardships of a growing project ,
( so it doesn't slow down to a stop ) .
( maemo.org wants a growing programming community, right ? )
So , for this and other reasons,
your post #1 still wants brainstorming.
Which is usually easier in smaller groups.
Perhaps, for a start, find a way of encouraging the "crazier" members to a mind-jam-session with "-rw-r--r-" permission.
( Let this forum continue to be and become better than the Linux world in general, which tends to leave beginners on their own until they are far enough to know what to ask.)
I'm used to being met with a hail of bullets. ;)
I was just wondering if something stronger might be feasible and useful, at least for perhaps a "premier" tier of apps. I may be just nuts based on responses though.
No, no, not nuts at all... I think I am starting to understand all these policy-creating people: forcing others into their policy gives them a feeling of accomplishment without doing any actual work, doesn't it? :)
attila77
2009-08-16, 11:08
So, can that be encouraged ?
Can beta testers be encouraged to look at (parts of) the source, and then somehow give karma ?
Can karma for easily understood code somehow make life easier for the project ?
One post pointed in a similar direction by suggesting karma for good management.
Just as a reference, ohloh (www.ohloh.net) has (an automatic) project analysis feature. Based on the specified source (you just specify a SCM), it takes a look and displays some info about it. For example, pidgin (http://www.ohloh.net/p/pidgin). Not saying it should be done in the same way, just saying that OSS project analysis is not a completely uncharted territory :)
KristianW
2009-08-16, 12:05
Just as a reference, ohloh (www.ohloh.net) has (an automatic) project analysis feature. Based on the specified source (you just specify a SCM), it takes a look and displays some info about it. For example, pidgin (http://www.ohloh.net/p/pidgin). Not saying it should be done in the same way, just saying that OSS project analysis is not a completely uncharted territory :)
I suppose that migh work about as well as grammer checking in a word processor.
It has benefits - and dangers, especially if the organization around pushes for compliance; then the result is often bad prose.
Good programming is (as writing) about well structured thinking.
Automatic checking might help having details well documented.
But the kind of code commenting and documentation I have in mind,
which helps the programmer to structure his thoughts and vision,
and also increases code maintainability,
can only be encouraged by human help.
EDIT :
I answered before reading your links.
Good !
Any structure that helps us humans
communicate efficiently,
helps here !
As other have kind of said before, Texrat's concerns are valid but I feel like we are working already on all of them in Fremantle:
- maemo.org Extras process considered the one and only valid for community apps to be recommended to real end users.
- Application Manager default UI can't even deal with .deb packages alone. Users willing to install them need to go through rootme and command line.
- Single entry point through extras-devel and con be only done by uploading the source code of the application and its dependencies.
- Packages go only through the extras-devel automatic filter if they reach a minimum of quality criteria: no missing dependencies or apps that don't install in extras-testing.
- Packages require human testing and approval to go through the extras-testing filter and reach Extras.
- Everybody be strict and recommend Extras and only Extras to pure end users. Big warning to those willing to get fresh meat in extras-testing. Everybody to understand that extras-devel is the wild wild west: don't complain if anything happens to your device, your family or yourself if you try it out. ;)
- Only Extras apps are promoted in maemo.nokia.com.
- The rest of Nokia looks only at maemo.nokia.com when it comes to promote community apps or projects.
Considering all this... what else would you do to signal and evaluate the quality of community projects?
attila77
2009-08-16, 16:19
@qgil: I was under the impression we're talking more developer oriented. The extras story is about *distribution*, but we're talking *development* here (unless I got it very wrong :) ). Something can pass through extras with flying colours because it's super-polished from a user aspect, but still be a one-man-show with author-only maintainable code in a private SCM.
Good point attila. I realize I haven't exactly been coherent (:D) but to an extent you're right: while I started the focus on distribution, development is also key. A robust workflow encompassing both is needed. Along those lines what Quim had to say was very reassuring-- I had just never seen it all pulled together like that. However, if what you say is true then that looks like another weak link...
BTW I'm working in software/hardware change management now so I'm learning!
Something can pass through extras with flying colours because it's super-polished from a user aspect, but still be a one-man-show with author-only maintainable code in a private SCM.
Perhaps worth repeating: if packages are in extras*, then by necessity so is the source (http://repository.maemo.org/extras-devel/pool/fremantle/free/source/). Worst case, we just lose the ability to "svn blame" and similar.
And what's wrong with one-man-show apps anyway?
Yes, you are absolutely right. But where's the problem? I don't know any open source projects for Maemo where source code isn't easily available from some public place.
Oh I'm sure there are some and I suspect that someone will point them out now that it's been mentioned. :rolleyes:
That will just distract from your point which I agree with that:
There aren't many abandoned open source projects for Maemo where source code isn't easily available. Certainly not enough to warrant the resources to design, develop, install, and maintain what would in essence be a YAR (yet another repository :) )
I was just wondering if something stronger might be feasible and useful, at least for perhaps a "premier" tier of apps. I may be just nuts based on responses though.
...as been said many times on this board, feel free to post your own list. :D
I can't name any offhand, either, but others have reported abandoned projects with no access to the latest source...
BTW, I think you may be misguided based on some responses.
There may not be many apps abandoned without source code available however, I agree that there are many apps that appear abandoned non the less.
Perhaps energy could be better spent developing good training material that casual users can be directed to so they can post patches and/or make the changes they want in existing apps.
...what is reported may not be due to lack of access to the latest source rather it may be lack of access to a way with which to encourage continued development.
To that^ I say; allowing or encouraging developer links to pay-pal or other donation sites does wonders. :)
attila77
2009-08-16, 19:56
Perhaps worth repeating: if packages are in extras*, then by necessity so is the source (http://repository.maemo.org/extras-devel/pool/fremantle/free/source/). Worst case, we just lose the ability to "svn blame" and similar.
I'm not sure that's true. Passing through the autobuilder (and ending up in extras) just means it builds - it can still contain blobs or other constituents you don't have the source to.
And what's wrong with one-man-show apps anyway?
Not inherently wrong, but if the one man goes, the app gets orphaned. It might survive, but it has significantly slimmer chances of survival than other open source projects where you have several developers who are familiar with the code.
...Perhaps energy could be better spent developing good training material that casual users can be directed to so they can post patches and/or make the changes they want in existing apps...
Do you mean something like this?
>> OS and SDK training site << (http://developer.palm.com/index.php?option=com_learn&view=learn)
:)
Heck I'm getting a great education from this thread.
I'm not sure that's true. Passing through the autobuilder (and ending up in extras) just means it builds - it can still contain blobs or other constituents you don't have the source to.
Well, yeah, but the context here is open source apps (or is it?). No amount of enticing or forcing someone to go through garage will help with closed apps or components :-)
Not inherently wrong, but if the one man goes, the app gets orphaned. It might survive, but it has significantly slimmer chances of survival than other open source projects where you have several developers who are familiar with the code.
Sure, it can happen. Even in group projects with large headcounts (trivial example: Hildon). If/when it does, since the source is available, interested parties can pick it up. If there are no interested parties, well, too bad, find something else to replace it. Software (whether open or closed) never comes with lifetime warranties.
In the meantime I hope no one is seriously suggesting that we are supposed to stop using apps written (mainly) by one author just in case that person gets bored and goes away. Or that we should somehow force extra developers to join such projects (and the projects to accept them). Both attitudes would be borderline mental disorders IMHO.
I guess I don't get what problem we're trying to solve here. Given access to the source of the latest release, what more assurance can we reasonably expect?
I can't name any offhand, either, but others have reported abandoned projects with no access to the latest source...
The only one I can think of is the maemo-specific ruby bindings (see thread starting here (http://talk.maemo.org/showthread.php?t=29683&page=6#post298242)). Somewhat ironically, it used to be on garage according to ohloh (http://www.ohloh.net/p/ruby-maemo) :-/
attila77
2009-08-16, 21:29
Well, yeah, but the context here is open source apps (or is it?). No amount of enticing or forcing someone to go through garage will help with closed apps or components :-)
I was talking about open source. There are a number of cases where you go the way of blobs, like when autobuilder does not support something, or for other advantages (i.e. I routinely use PyZipFile in my PyQt projects to save users some space and speed up loading times).
In the meantime I hope no one is seriously suggesting that we are supposed to stop using apps written (mainly) by one author just in case that person gets bored and goes away. Or that we should somehow force extra developers to join such projects (and the projects to accept them). Both attitudes would be borderline mental disorders IMHO.
No, no, nothing alike. Not *force* but *ease* the process of picking up orphaned or joining projects. When you go to a project, you don't have a clue who does what, does it have a BDFL, who are the developers, who the power users, what are the tech parameters, etc, etc. It just saves a whole lot of time if you can find that out quickly, and increases the possibility of people joining in, which is the bottom line.
Ima: please try harder to avoid forcing the topic to extremes. ;)
There are a number of cases where you go the way of blobs, like when autobuilder does not support something
Ouch, I had no idea :-( These cases should be filed in bugzilla, forcing developers to resort to that is broken.
vBulletin® v3.8.8, Copyright ©2000-2024, vBulletin Solutions, Inc.